Courseiva

Kubernetes and Cloud Native Security Associate (KCSA, CNCF) (KCSA) (KCSA) — Questions 151–225

292 questions total · 4 pages · All types, answers revealed

Take a mock examExam hub
Page 2

Page 3 of 4

Page 4
151
MCQhard

A security team implements mutual TLS (mTLS) between all microservices using Istio Service Mesh. Which principle of cloud native security does this implementation primarily exemplify?

A.Zero-trust network segmentation and encryption in transit
B.Perimeter-based network defense
C.Shared fate computing
D.Physical host isolation
AnswerA

mTLS requires every microservice to present and verify certificates, authenticating both ends of each connection. Istio enforces this identity-based verification plus encryption in transit, which is exactly the zero-trust segmentation and encrypted-transit principle the stem asks about.

Why this answer

Implementing mTLS between all microservices with Istio exemplifies zero-trust network segmentation and encryption in transit. Zero-trust assumes no implicit trust based on network location; every service must authenticate and encrypt its traffic. mTLS provides both mutual authentication (both sides present certificates) and encryption, which is the core of zero-trust service-to-service communication.

Exam trap

KCSA often tests the confusion between zero-trust and perimeter security — candidates may pick 'perimeter-based' because mTLS is about network traffic, but the correct principle is zero-trust segmentation and encryption in transit.

How to eliminate wrong answers

Option B is wrong because perimeter-based defense relies on a trusted internal network and a hardened boundary — the opposite of zero-trust, which assumes the network is hostile. Option C is wrong because shared fate computing refers to designing systems where components fail together gracefully (e.g., bulkheads, circuit breakers), not to authentication/encryption. Option D is wrong because physical host isolation is an infrastructure control, not a service-mesh authentication mechanism.

Full explanation →
152
MCQhard

You are troubleshooting a custom controller that fails to read ConfigMaps in the 'kube-system' namespace despite having a ClusterRole bound via a ClusterRoleBinding. What is the most likely reason for this failure?

A.The ClusterRole lacks the required verbs ('get', 'list', 'watch') or resources ('configmaps') for that API group.
B.ClusterRoleBindings cannot be used with ConfigMaps.
C.ClusterRoleBindings are automatically disabled in 'kube-system'.
D.ConfigMaps in 'kube-system' can only be accessed using ServiceAccounts named 'default'.
AnswerA

A ClusterRoleBinding grants whatever permissions the referenced ClusterRole defines; if that role omits get, list or watch on configmaps in the core API group, every request is denied by RBAC regardless of the binding's scope.

Why this answer

A ClusterRole defines permissions on cluster-scoped resources or across all namespaces. If the ClusterRole bound to the controller's ServiceAccount does not include 'get', 'list', 'watch' on 'configmaps' in the relevant API group, the controller cannot read ConfigMaps in any namespace, including kube-system.

Exam trap

KCSA often tests RBAC details, and candidates may assume that a ClusterRoleBinding automatically grants full access, forgetting that the ClusterRole must explicitly include the required verbs and resources.

How to eliminate wrong answers

Option B is wrong because ClusterRoleBindings can grant access to any resource, including ConfigMaps. Option C is wrong because ClusterRoleBindings are not disabled in kube-system; they work cluster-wide. Option D is wrong because ConfigMaps in kube-system are not restricted to the default ServiceAccount; any ServiceAccount with proper RBAC can access them.

Full explanation →
153
MCQmedium

An attacker who achieves remote code execution inside a misconfigured container discovers that the service account token mounted at /var/run/secrets/kubernetes.io/serviceaccount/token has cluster-wide administrative permissions. Which Kubernetes security feature should be enabled on the ServiceAccount to mitigate the risk of token theft and misuse?

A.Disabling automatic token mounting (automountServiceAccountToken: false) and utilizing projected volumes with bound audiences
B.Configuring a default Deny-All NetworkPolicy for the kube-system namespace
C.Enabling the NodeRestriction admission plugin
D.EnablingAnonymousAuth on the kube-apiserver
AnswerA

Disabling automatic token mounting stops Kubernetes injecting a credential into every pod, so a compromised container no longer finds a usable token at the default path. Projected volumes with bound audiences then issue short-lived, audience-restricted tokens, limiting what a stolen credential can access cluster-wide.

Why this answer

Disabling automountServiceAccountToken and using projected volumes with bound audiences limits the blast radius of token theft because the token is only issued when explicitly requested and is scoped to a specific audience and expiry. This prevents an attacker with RCE from finding a long-lived, cluster-admin token automatically mounted in the pod filesystem. Projected tokens are also time-bound and rotated, so stolen tokens expire quickly.

Exam trap

KCSA often tests the misconception that network policies or admission plugins can mitigate token theft, when the core issue is the automatic mounting and long-lived nature of ServiceAccount tokens.

How to eliminate wrong answers

Option B is wrong because a Deny-All NetworkPolicy in kube-system only restricts network traffic and does nothing to prevent token theft or misuse from within a pod. Option C is wrong because the NodeRestriction admission plugin limits what kubelets can modify about Node and Pod objects; it does not address ServiceAccount token mounting or permissions. Option D is wrong because enabling AnonymousAuth on the kube-apiserver allows unauthenticated requests, which worsens security rather than mitigating token theft.

Full explanation →
154
MCQeasy

Which of the following represents a common cloud-native supply chain attack vector where malicious actors publish packages with names similar to popular libraries?

A.Kernel memory exploitation via unprivileged user namespaces
B.Denial of Service via packet flooding
C.Man-in-the-Middle etcd keystore sniffing
D.Typosquatting
AnswerD

Typosquatting registers package names closely resembling legitimate popular libraries, hoping developers mistype and install the malicious lookalike. This impersonation of trusted names is the defining mechanism of the supply chain vector described, distinguishing it from dependency confusion or account compromise.

Why this answer

Typosquatting is a supply chain attack where adversaries publish malicious packages with names closely resembling legitimate, popular libraries (e.g., 'lodahs' instead of 'lodash'). Developers who mistype the package name during installation inadvertently pull in malicious code. This is a well-documented cloud-native supply chain threat affecting npm, PyPI, and container registries.

Exam trap

KCSA often tests whether candidates can distinguish supply chain attacks (typosquatting, dependency confusion) from runtime or network attacks, causing confusion when technically plausible but unrelated options are presented.

How to eliminate wrong answers

Option A (Kernel memory exploitation via unprivileged user namespaces) is wrong because it describes a kernel-level privilege escalation technique, not a package-name-based supply chain attack. Option B (Denial of Service via packet flooding) is wrong because it describes a network-layer volumetric attack, unrelated to package publishing. Option C (Man-in-the-Middle etcd keystore sniffing) is wrong because it describes interception of etcd traffic (a control plane attack), not a supply chain vector involving malicious package publication.

Full explanation →
155
MCQmedium

You are deploying a ValidatingWebhookConfiguration to inspect incoming pod creations. What happens if the webhook fails and the 'failurePolicy' in the webhook configuration is set to 'Fail'?

A.The API request is allowed to proceed without validation.
B.The API request is rejected.
C.The pod is created in a suspended state until the webhook recovers.
D.The kube-apiserver restarts automatically.
AnswerB

With failurePolicy set to Fail, the API server treats an unreachable or erroring webhook as a denial, so the admission chain halts and the pod creation request is rejected rather than admitted. This enforces the stem's inspection guarantee even during webhook outages.

Why this answer

When failurePolicy is set to Fail, the API server treats any webhook call failure (network error, timeout, non-2xx response) as a denial, so the pod creation request is rejected. This is the safe default for security-critical validation because it prevents unvalidated resources from being admitted. The request fails closed rather than open.

Exam trap

The trap is mixing up failurePolicy: Fail with failurePolicy: Ignore — candidates often assume a webhook failure always blocks the request, but only Fail does; Ignore lets it through.

How to eliminate wrong answers

Option A is wrong because allowing the request to proceed describes failurePolicy: Ignore, not Fail. Option C is wrong because Kubernetes has no 'suspended pod' state tied to webhook recovery; pods are either admitted or rejected, and Pending only reflects scheduling/container startup, not admission. Option D is wrong because the kube-apiserver does not restart on webhook failures; it simply returns an error to the client, and the webhook is an external HTTP endpoint the API server calls.

Full explanation →
156
MCQmedium

A security team discovers that a vulnerability in a third-party open-source npm library has been exploited inside a running container in a production Kubernetes cluster. Based on the 4Cs of Cloud Native Security, which layer should be modified first to fix the root cause of this vulnerability?

A.Container layer
B.Code layer
C.Cluster layer
D.Cloud layer
AnswerB

The vulnerable npm library is application source code, so remediation belongs at the Code layer of the 4Cs model. Patching or upgrading the dependency, then rebuilding the image, eliminates the root cause rather than merely containing it. Container, cluster and cloud layers cannot fix a defect originating in third-party application code.

Why this answer

In the 4Cs of Cloud Native Security (Cloud, Cluster, Container, Code), the Code layer refers to the application code and its dependencies. Since the vulnerability is in a third-party npm library used by the application, fixing the root cause requires updating or patching that library in the application code, which is part of the Code layer.

Exam trap

KCSA often tests the 4Cs model, and candidates may confuse the Container layer with the Code layer, thinking that container scanning alone fixes vulnerabilities, but the root cause is in the code dependencies.

How to eliminate wrong answers

Option A is wrong because the Container layer involves the container image and runtime, but the vulnerability originates from the application's dependency, not the container base image. Option C is wrong because the Cluster layer concerns the orchestration and infrastructure, not application dependencies. Option D is wrong because the Cloud layer refers to the underlying cloud infrastructure, which is not where the vulnerability resides.

Full explanation →
157
MCQeasy

A security engineer is designing a defense-in-depth strategy for a cloud native application deployment. Which of the following best exemplifies the 'defense-in-depth' principle across the 4Cs layers?

A.Granting cluster-admin permissions to all developers to ensure rapid troubleshooting.
B.Disabling authentication mechanisms to reduce operational overhead.
C.Applying strong firewall rules only at the perimeter of the corporate network.
D.Implementing security controls at every layer from Code to Cloud so that a compromise at one layer does not result in total system failure.
AnswerD

Defence-in-depth layers independent controls across Code, Container, Cluster and Cloud, so bypassing one control does not grant full access. This satisfies the stem's requirement for coverage across all 4Cs rather than hardening a single layer.

Why this answer

Defense-in-depth across the 4Cs means implementing security controls at every layer — Cloud, Cluster, Container, and Code — so that a compromise at one layer does not cascade into total system failure. This layered approach ensures no single point of failure exists in the security posture.

Exam trap

KCSA often tests whether candidates confuse defense-in-depth with perimeter defense — the exam includes perimeter-only and disabled-authentication options that sound like simplifications but actually eliminate security layers.

How to eliminate wrong answers

Option A is wrong because granting cluster-admin to all developers violates least privilege and creates a massive privilege escalation risk — it is the opposite of defense-in-depth. Option B is wrong because disabling authentication removes the ability to verify identity, which is a foundational security control; it eliminates a layer rather than adding one. Option C is wrong because perimeter-only firewall rules assume the network boundary is sufficient, which fails against insider threats and compromised credentials that originate inside the perimeter.

Full explanation →
158
MCQmedium

An auditor notices that the kubelet on worker nodes is configured with --protect-kernel-defaults=true. What is the security purpose of this flag?

A.It ensures that critical kernel parameters match expected secure baseline settings and prevents unauthorized modification.
B.It encrypts all kernel log (kmsg) outputs.
C.It prevents the Linux kernel from running container workloads as root.
D.It forces the kubelet to run inside an isolated kernel container.
AnswerA

With --protect-kernel-defaults=true, the kubelet refuses to start if sysctl values differ from its expected secure baseline, and it will not modify them itself. This enforces consistent kernel hardening across nodes and blocks drift that could weaken container isolation.

Why this answer

The --protect-kernel-defaults flag in the kubelet enforces that certain kernel parameters (sysctls) and kernel module settings match the kubelet's expected secure defaults. When enabled, the kubelet will fail to start or will refuse to run pods if it detects that critical kernel tunables—such as those related to IP forwarding, memory overcommit, or panic settings—have been changed from the kubelet's built-in safe values. This prevents accidental or malicious modification of kernel settings that could weaken container isolation or destabilize the node.

Exam trap

KCSA often tests confusing security flags with similar-sounding purposes; candidates may mistakenly think --protect-kernel-defaults encrypts logs or enforces rootless containers, when it actually validates kernel parameters against secure defaults.

How to eliminate wrong answers

Option B is wrong because --protect-kernel-defaults does not encrypt kernel log outputs; kernel log encryption is not a kubelet feature and would typically involve other mechanisms like auditd or secure logging. Option C is wrong because the flag does not prevent containers from running as root; rootless containers are enforced by other means such as user namespaces or Pod Security Standards. Option D is wrong because the kubelet always runs as a host process, not inside a kernel container; the flag concerns kernel parameter validation, not kubelet isolation.

Full explanation →
159
MCQeasy

Under the cloud native shared responsibility model, who is responsible for ensuring that the underlying physical servers and hardware security modules (HSMs) are secure and compliant?

A.The container registry administrator
B.The application developer
C.The Kubernetes administrator
D.The cloud service provider
AnswerD

Under the cloud native shared responsibility model, the cloud service provider owns security of the cloud: physical servers, hardware, and HSMs in its data centres. This satisfies the requirement, as customers cannot secure hardware they do not control.

Why this answer

Under the cloud native shared responsibility model, the cloud service provider (CSP) owns and operates the physical infrastructure layer — data centers, physical servers, networking hardware, and hardware security modules (HSMs). Customers consume these as abstracted services and cannot patch, inspect, or physically secure them, so the CSP is contractually and technically responsible for their security and compliance (e.g., FIPS 140-2 validated HSMs, SOC 2, ISO 27001 attestations).

Exam trap

KCSA often tests the boundary of the shared responsibility model — candidates incorrectly assume that because they 'own' their workloads they also own the physical layer, when in fact the CSP always retains responsibility for physical servers, hypervisors, and HSMs.

How to eliminate wrong answers

Option A is wrong because a container registry administrator only manages image repositories, access policies, and vulnerability scanning of stored artifacts — they have no visibility or control over physical hardware. Option B is wrong because application developers operate at the code/container layer and cannot influence physical server or HSM security. Option C is wrong because a Kubernetes administrator manages cluster-level resources (RBAC, workloads, namespaces, node pools) but the physical hosts and HSMs sit beneath the abstraction boundary owned by the CSP.

Full explanation →
160
MCQeasy

Which service account permission model is used by default when a pod is created without specifying a service account name?

A.The 'default' service account in the pod's namespace.
B.No service account is assigned.
C.The 'cluster-admin' service account.
D.The 'kube-system' privileged service account.
AnswerA

Kubernetes automatically mounts the namespace's 'default' ServiceAccount token into every pod lacking an explicit serviceAccountName. That identity, not a cluster-wide or admin account, is what the API server authenticates, so permissions are limited to whatever RBAC grants that default account.

Why this answer

When a pod is created without specifying a serviceAccountName, Kubernetes automatically assigns the 'default' service account from the pod's namespace. This is a built-in behavior: every namespace has a 'default' ServiceAccount created automatically, and the admission controller injects it if none is specified. This default account typically has no extra permissions beyond basic API discovery, but it still exists and can be used for identity.

Exam trap

KCSA often tests the misconception that pods run without any service account or that they get a privileged one by default; the trap is forgetting that the 'default' ServiceAccount is automatically assigned and can be a security risk if not audited.

How to eliminate wrong answers

Option B is wrong because Kubernetes always assigns a service account (the 'default' one) if none is specified; a pod cannot run without a service account identity in modern Kubernetes. Option C is wrong because 'cluster-admin' is a highly privileged ClusterRole binding, not a service account, and it is never assigned by default. Option D is wrong because 'kube-system' is a namespace, not a service account, and pods in other namespaces do not get a privileged service account from kube-system by default.

Full explanation →
161
MCQeasy

Which component is responsible for executing probes (liveness, readiness, startup) against containers running on a worker node?

A.kube-scheduler
B.kube-controller-manager
C.kubelet
D.kube-apiserver
AnswerC

The kubelet runs on each worker node as the node agent and directly manages pod containers. It executes liveness, readiness and startup probes locally against those containers, reporting results to the API server, so probe execution never depends on the control plane.

Why this answer

The kubelet is the node agent that runs on every worker node and is responsible for managing Pod lifecycle on that node. It receives PodSpecs from the API server and executes the actual container runtime operations, including running liveness, readiness, and startup probes against containers via the container runtime interface (CRI). The kubelet interprets probe definitions (httpGet, tcpSocket, exec, grpc) and periodically executes them, taking action such as restarting containers on liveness failure or removing Pods from Service endpoints on readiness failure.

Exam trap

The trap here is confusing control-plane components with the node agent — candidates often assume the kube-controller-manager or kube-apiserver runs probes because they 'manage' Pods, but probe execution is strictly a kubelet responsibility on the worker node.

How to eliminate wrong answers

Option A is wrong because the kube-scheduler only decides which node a Pod should be placed on based on resource requests, affinity, taints, and other scheduling constraints — it never interacts with running containers. Option B is wrong because the kube-controller-manager runs control-plane reconciliation loops (Deployment, ReplicaSet, Node, Endpoint controllers) and does not execute probes against containers. Option D is wrong because the kube-apiserver is the REST front-end for the cluster — it stores and serves object state but does not run probes; it merely persists probe configuration in the PodSpec.

Full explanation →
162
Multi-Selecthard

Which THREE configurations should be applied to a Kubernetes Pod Security Standard 'restricted' profile compliance checklist? (Choose three)

Select 3 answers
A.Allowing privileged: true for all application containers
B.Restricting container capabilities to drop ALL and only permit essential ones like NET_BIND_SERVICE
C.Setting allowPrivilegeEscalation to false in the container securityContext
D.Mounting the host root filesystem in read-write mode
E.Requiring runAsNonRoot to be true
AnswersB, C, E

Dropping ALL Linux capabilities and adding back only required ones, such as NET_BIND_SERVICE, satisfies the restricted profile's capability constraint. The restricted policy mandates that containers drop every capability, permitting additions solely from a defined allowlist, which prevents privilege escalation through unnecessary kernel privileges.

Why this answer

The Kubernetes Pod Security Standard 'restricted' profile is the most hardened policy, so option B is correct because it mandates dropping ALL Linux capabilities and only adding back the minimal ones actually needed (e.g., NET_BIND_SERVICE), which follows the least-privilege principle. Option C is correct because the restricted profile explicitly requires allowPrivilegeEscalation: false in the container securityContext to prevent processes from gaining more privileges than their parent (e.g., via setuid binaries or file capabilities). Option E is correct because runAsNonRoot: true is required so the kubelet validates that containers do not run as UID 0, blocking root-owned processes.

Option A does not belong because privileged: true is forbidden by the restricted profile, as it grants nearly all host capabilities and device access. Option D does not belong because mounting the host root filesystem read-write is prohibited; the restricted profile disallows hostPath volumes and requires read-only root filesystems where applicable.

Exam trap

The trap is selecting options that seem secure but are actually prohibited, like allowing privileged containers or read-write host mounts. Candidates must remember that restricted profile is about denying all but the most essential permissions.

Full explanation →
163
MCQeasy

An administrator needs to evaluate an existing Kubernetes cluster against the CIS Kubernetes Benchmark. Which tool provides automated scanning specifically tailored to this benchmark?

A.kube-hunter
B.falco
C.velero
D.kube-bench
AnswerD

kube-bench runs the CIS Kubernetes Benchmark checks directly against cluster components, covering control plane, nodes, policies and etcd. It is purpose-built for that benchmark, unlike general vulnerability or configuration scanners, so it satisfies the requirement for automated scanning specifically tailored to CIS.

Why this answer

kube-bench is an open-source tool from Aqua Security that runs automated checks directly against the CIS Kubernetes Benchmark, inspecting control plane components, kubelet configuration, and node settings. It reports PASS/FAIL/WARN results mapped to specific CIS controls, making it the purpose-built tool for benchmark evaluation.

Exam trap

KCSA often tests tool-purpose mapping, baiting candidates who confuse offensive scanners (kube-hunter) or runtime detectors (Falco) with compliance benchmark tools like kube-bench.

How to eliminate wrong answers

Option A is wrong because kube-hunter is an offensive penetration-testing tool that probes for exploitable vulnerabilities from an attacker's perspective, not a CIS benchmark scanner. Option B is wrong because Falco is a runtime security tool that detects anomalous syscall and container behavior via eBPF/kernel modules, not a configuration benchmark scanner. Option C is wrong because Velero is a backup and disaster-recovery tool for Kubernetes cluster resources and persistent volumes, unrelated to CIS compliance.

Full explanation →
164
MCQmedium

An organization requires that all container images pulled into a Kubernetes cluster are cryptographically signed and verified before execution. Which tool integrates with Kubernetes admission control to enforce signature verification using Cosign?

A.Cilium CNI plugin
B.Metrics-server
C.Kyverno policy engine
D.Helm package manager
AnswerC

Kyverno acts as a validating admission webhook, evaluating policies against pod specifications and rejecting workloads whose images lack valid Cosign signatures. This enforces cryptographic verification before execution, directly satisfying the stem's requirement that only signed images run in the cluster.

Why this answer

Kyverno is a Kubernetes-native policy engine that runs as a dynamic admission controller and can validate, mutate, and generate resources. It supports verifying Cosign signatures on container images via its verifyImages rule, rejecting any pod whose image lacks a valid signature from a trusted key or keyless identity. This makes it the correct tool for enforcing cryptographic image verification at admission time.

Exam trap

KCSA often tests candidates who assume any admission-capable tool (like Helm or Cilium) can verify Cosign signatures, when only policy engines with explicit image verification support can do so.

How to eliminate wrong answers

Option A is wrong because Cilium is a CNI and eBPF-based networking/security plugin focused on network policy and observability, not image signature verification. Option B is wrong because metrics-server only collects resource metrics for HPA and kubectl top, with no admission or policy capability. Option D is wrong because Helm is a package manager for templating and deploying Kubernetes manifests, not an admission controller that verifies image signatures.

Full explanation →
165
MCQeasy

In a cloud native environment, what is the primary security purpose of using static code analysis (SAST) and software composition analysis (SCA) tools in the CI/CD pipeline?

A.To provision cloud networking security groups automatically
B.To manage worker node operating system updates
C.To identify vulnerabilities and insecure coding patterns in the Code layer before deployment
D.To detect running process anomalies in production pods
AnswerC

SAST inspects source code for insecure patterns, while SCA identifies vulnerable dependencies, both operating on the Code layer. Running them in the CI/CD pipeline catches these flaws before deployment, satisfying the requirement to secure the Code layer early.

Why this answer

SAST tools analyze source code for insecure coding patterns such as SQL injection or hardcoded secrets, while SCA tools identify vulnerable open-source dependencies and their licenses. Both operate on the Code layer of the CI/CD pipeline, catching issues before deployment, which is far cheaper than remediating in production.

Exam trap

KCSA often tests the confusion between static analysis (code layer) and runtime security (production), so candidates may incorrectly select options about monitoring running pods or managing infrastructure.

How to eliminate wrong answers

Option A is wrong because provisioning cloud networking security groups is an infrastructure-as-code or cloud automation task, not the purpose of SAST/SCA. Option B is wrong because managing worker node OS updates is a runtime infrastructure concern, typically handled by the cloud provider or node management tools, not by code analysis. Option D is wrong because detecting running process anomalies in production pods is runtime security (e.g., Falco, eBPF), not static analysis.

Full explanation →
166
MCQhard

An organization is building a secure software supply chain for Kubernetes. They want to ensure that containers running in the cluster were built from verified source code and passed automated security gates. Which tool combination supports this attestation and verification pipeline?

A.Cosign for cryptographic image signing, SBOM generation, and admission controllers for policy enforcement
B.HorizontalPodAutoscaler and Metrics Server integration
C.kube-proxy for CNI routing and CoreDNS for internal name resolution
D.etcd snapshots and kubeadm control plane bootstrapping scripts
AnswerA

Cosign produces verifiable signatures and attestations tied to the image digest, while admission controllers enforce that only signed, policy-compliant images are admitted. Together they satisfy the stem's requirement for verified source provenance and automated security gates.

Why this answer

Cosign provides cryptographic signing and verification of container images, and can attach SBOMs and attestations (e.g., SLSA provenance) to images in OCI registries. Admission controllers such as Kyverno, OPA Gatekeeper, or Sigstore's policy-controller then enforce at admission time that only images with valid signatures/attestations are admitted to the cluster. Together they form the attestation-and-verification pipeline the question describes.

Exam trap

KCSA often tests whether candidates confuse supply-chain security tooling (Cosign, SBOM, admission policy) with general cluster operations tooling (HPA, kube-proxy, etcd), so the trap is picking a familiar Kubernetes component that has nothing to do with image provenance.

How to eliminate wrong answers

Option B is wrong because HorizontalPodAutoscaler and Metrics Server are workload-scaling components — they have no role in image provenance, signing, or supply-chain attestation. Option C is wrong because kube-proxy handles Service VIP/iptables-IPVS routing and CoreDNS handles in-cluster DNS resolution; neither verifies image origin. Option D is wrong because etcd snapshots and kubeadm bootstrap scripts address control-plane backup and cluster provisioning, not container image attestation.

Full explanation →
167
MCQeasy

An auditor is reviewing the Kubernetes attack surface and notes that a container is running with privileged: true in its securityContext. Which threat model risk does this setting introduce?

A.It prevents the container from writing to ephemeral storage volumes.
B.It forces the kubelet to restart the container continuously due to failing readiness probes.
C.It completely disables the Kubernetes DNS resolution service for the pod.
D.It disables container isolation, granting the container root-equivalent access to the underlying host node.
AnswerD

privileged: true grants the container all Linux capabilities and unrestricted device access, effectively removing namespace isolation. The container can then access host resources as root, satisfying the stem's concern about root-equivalent access to the underlying node.

Why this answer

Setting privileged: true in a container's securityContext disables the container's isolation from the host by granting it all Linux capabilities and access to host devices. This effectively gives the container root-equivalent control over the underlying node, allowing it to escape the container boundary, access host filesystems, and compromise the node and potentially the whole cluster.

Exam trap

KCSA often tests whether candidates understand that privileged: true removes container isolation and grants host-level access, rather than confusing it with unrelated behaviors like storage restrictions, probe failures, or DNS disruption.

How to eliminate wrong answers

Option A is wrong because privileged mode does not restrict ephemeral storage writes; if anything, it broadens access to host resources. Option B is wrong because privileged mode has no relationship to readiness probes or kubelet restart behavior — those are governed by probe configuration and restartPolicy. Option C is wrong because privileged mode does not disable DNS resolution; CoreDNS and pod DNS settings operate independently of the securityContext privileged flag.

Full explanation →
168
MCQmedium

An application pod needs to access the Kubernetes API server securely. How does Kubernetes authenticate the pod by default when it communicates with the API server?

A.Using static username and password credentials stored in environment variables.
B.Using a ServiceAccount bearer token mounted inside the pod's filesystem.
C.Using mutual TLS (mTLS) client certificates generated by the kubelet on startup.
D.Using SSH keys stored in the pod's root directory.
AnswerB

The kubelet projects a bound ServiceAccount token into the pod's filesystem, which the application presents as a bearer token to the API server. The API server validates it against the ServiceAccount, authenticating the pod's identity without embedding long-lived credentials in the image.

Why this answer

By default, Kubernetes authenticates pods to the API server using the ServiceAccount token that is automatically mounted into the pod at /var/run/secrets/kubernetes.io/serviceaccount/token. The kubelet projects this token into the pod, and the API server validates it as a bearer token tied to the pod's ServiceAccount identity. This is the standard in-cluster authentication mechanism.

Exam trap

KCSA often tests the misconception that pods use client certificates or static credentials, when the default is the auto-mounted ServiceAccount bearer token.

How to eliminate wrong answers

Option A is wrong because static username/password credentials are a legacy, deprecated mechanism and are not the default for pods. Option C is wrong because while the API server uses mutual TLS for client certificate authentication, the kubelet does not generate per-pod client certificates on startup for pod authentication; pods use ServiceAccount tokens instead. Option D is wrong because SSH keys are unrelated to Kubernetes API authentication and are never used for this purpose.

Full explanation →
169
MCQmedium

An organization wants to prevent supply chain attacks where compromised base images are pulled from public registries. Which control directly addresses this risk in a cloud native environment?

A.Implementing Kubernetes Horizontal Pod Autoscalers
B.Disabling all outbound internet access from cluster worker nodes
C.Enabling audit logging on the Kubernetes API server
D.Restricting container image pulls to approved, scanned internal registries using admission controllers
AnswerD

Admission controllers validate pod specs at creation, rejecting images whose registry is not on the approved internal list. This enforces the constraint that only scanned, trusted images are pulled, blocking compromised public base images before they reach nodes.

Why this answer

Restricting container image pulls to approved, scanned internal registries using admission controllers directly prevents compromised base images from public registries from being deployed. Admission controllers can enforce policies that reject pods referencing untrusted registries, ensuring only vetted images run in the cluster. This is a targeted supply chain control.

Exam trap

The trap is choosing broad network controls (disabling internet) or logging (audit) instead of the precise admission-controller-based registry restriction that directly addresses image provenance.

How to eliminate wrong answers

Option A is wrong because Horizontal Pod Autoscalers adjust replica counts based on load, not image provenance or registry restrictions. Option B is wrong because disabling outbound internet access is a broad network control that may break legitimate dependencies and does not specifically validate image sources; it also does not prevent pulling from public registries if a proxy or mirror is used. Option C is wrong because audit logging records API activity for forensics and compliance but does not block or prevent compromised image pulls.

Full explanation →
170
MCQmedium

A security auditor discovers that anonymous authentication is accidentally enabled on the Kubernetes API server, allowing unauthenticated read access to cluster health endpoints. Which API server flag must be modified to disable anonymous requests?

A.--secure-port=0
B.--authorization-mode=AlwaysAllow
C.--anonymous-auth=false
D.--disable-anonymous=true
AnswerC

Setting `--anonymous-auth=false` on the kube-apiserver forces every request to present valid credentials, rejecting unauthenticated calls to health endpoints such as `/healthz` and `/livez`. This directly satisfies the auditor's requirement to disable anonymous access, since the flag governs whether requests lacking authentication are treated as the `system:anonymous` user.

Why this answer

The --anonymous-auth flag on kube-apiserver controls whether unauthenticated requests are treated as anonymous users (system:anonymous). Setting --anonymous-auth=false rejects requests without valid credentials with a 401 Unauthorized response, closing the exposure of health/version endpoints to unauthenticated clients. This is the documented, supported way to disable anonymous access and is enforced by CIS Kubernetes Benchmark control 1.2.1.

Exam trap

The trap here is confusing the kube-apiserver flag --anonymous-auth with the kubelet's authentication.anonymous.enabled setting, or inventing plausible-sounding flags like --disable-anonymous that don't exist.

How to eliminate wrong answers

Option A is wrong because --secure-port=0 disables the HTTPS serving port entirely, which would break all API access rather than just anonymous requests. Option B is wrong because --authorization-mode=AlwaysAllow is the opposite of what's needed — it permits every authenticated (and anonymous) request, worsening the exposure. Option D is wrong because --disable-anonymous is not a real kube-apiserver flag; the correct flag is --anonymous-auth.

Full explanation →
171
MCQmedium

A developer builds a Docker container image using an outdated base image that contains known critical operating system vulnerabilities. Before deploying this image to a production Kubernetes cluster, which security practice should be enforced to detect this issue?

A.Enabling Kubernetes Role-Based Access Control (RBAC).
B.Configuring static container image vulnerability scanning in the CI/CD pipeline.
C.Deploying a network mesh like Istio with mutual TLS.
D.Applying Pod Security Standards at the Restricted level.
AnswerB

Static scanning in the CI/CD pipeline inspects the built image against vulnerability databases before deployment, catching known OS package flaws inherited from the outdated base image. This satisfies the stem's requirement to detect critical vulnerabilities prior to production release.

Why this answer

Configuring static container image vulnerability scanning in the CI/CD pipeline is correct because it inspects the image's OS packages and application dependencies against CVE databases before the image is deployed. This directly detects outdated base images with known critical vulnerabilities, allowing the pipeline to fail the build or block promotion. It is the earliest and most cost-effective control point for this class of issue.

Exam trap

KCSA often tests whether candidates confuse runtime hardening controls (RBAC, PSS, mTLS) with supply-chain controls (image scanning); the trap is picking a runtime control for a build-time vulnerability detection problem.

How to eliminate wrong answers

Option A is wrong because RBAC controls who can perform actions on Kubernetes API resources; it does not inspect image contents for CVEs. Option C is wrong because Istio with mutual TLS secures service-to-service communication (encryption and identity), not the vulnerability status of container images. Option D is wrong because Pod Security Standards Restricted level enforces runtime pod hardening (non-root, no privileged, seccomp), but does not scan for known OS vulnerabilities in the image.

Full explanation →
172
MCQmedium

A security engineer wants to inspect container runtime logs for potential security violations or runtime errors. Which log file or mechanism on a worker node managed by systemd and containerd provides container lifecycle events?

A.kubectl get events --all-namespaces
B.journalctl -u containerd
C./var/log/coredns.log
D./var/log/kube-apiserver.log
AnswerB

Containerd runs as a systemd unit, so its lifecycle events, image pulls and runtime errors are captured in the journal. Querying that unit with journalctl retrieves exactly those container events, matching the requirement to inspect runtime logs on a systemd-managed worker node.

Why this answer

On a worker node managed by systemd and containerd, container lifecycle events and runtime logs are captured by the containerd service. Using journalctl -u containerd retrieves these logs from the systemd journal, providing visibility into container start, stop, and errors. This is the correct mechanism for inspecting runtime logs at the node level.

Exam trap

KCSA often tests the difference between Kubernetes-level events (kubectl get events) and node-level runtime logs; candidates may incorrectly choose kubectl commands when the question specifies worker node and containerd.

How to eliminate wrong answers

Option A is wrong because kubectl get events retrieves Kubernetes API events, not container runtime logs, and may not include low-level containerd errors. Option C is wrong because /var/log/coredns.log is specific to CoreDNS, which handles DNS, not container runtime. Option D is wrong because /var/log/kube-apiserver.log is for the API server, not the container runtime on a worker node.

Full explanation →
173
Multi-Selectmedium

A security architect is designing role-based access control (RBAC) to comply with NIST access control principles of least privilege. Which THREE best practices should be followed when creating Roles and ClusterRoles? (Choose THREE)

Select 3 answers
A.Scrutinize and restrict the use of ClusterRoleBindings to cluster-wide resources
B.Avoid using wildcards (*) in API groups, resources, and verbs where possible
C.Allow all users to read Kubernetes Secrets by default
D.Grant cluster-admin permissions to all application service accounts for ease of deployment
E.Regularly audit RBAC permissions and bindings
AnswersA, B, E

Restricting ClusterRoleBindings to genuinely cluster-scoped resources prevents namespace-bound workloads inheriting cluster-wide permissions, directly enforcing least privilege. Because ClusterRoleBindings grant access across every namespace, scrutinising each binding limits lateral movement and privilege escalation, satisfying NIST's requirement that subjects receive only the minimum access necessary for their function.

Why this answer

Option A is correct because ClusterRoleBindings grant permissions across the entire cluster, so they should be tightly scrutinized and reserved for genuinely cluster-scoped resources to uphold least privilege. Option B is correct because wildcards (*) in API groups, resources, or verbs grant far broader access than intended, violating least privilege and increasing blast radius; explicit permissions should be enumerated instead. Option E is correct because RBAC permissions drift over time as roles and bindings accumulate, so regular auditing is essential to detect and remove excessive or stale privileges.

Options C and D are incorrect: allowing all users to read Secrets by default and granting cluster-admin to all service accounts both directly violate least privilege by providing excessive, unnecessary access.

Exam trap

The trap is that options C and D sound like they simplify administration, but they directly contradict least privilege; candidates must recognize that convenience is not a security best practice.

Full explanation →
174
MCQhard

A security team is evaluating the attack surface of the Kubernetes control plane. They notice that the kubelet API port 10250 is accessible from the internal pod network without proper authorization checks if authentication defaults are misconfigured. What is the primary threat vector associated with an unauthenticated, accessible kubelet API?

A.Execution of arbitrary commands inside running containers via the kubelet exec and run endpoints
B.Direct modification of etcd key-value pairs stored on the master node
C.Bypassing container image vulnerability scanners running in the CI/CD pipeline
D.Forcing the API server to issue new root certificates via TLS bootstrapping
AnswerA

The kubelet's exec and run endpoints proxy directly to the container runtime, so unauthenticated access on port 10250 permits arbitrary command execution inside any pod on that node. This satisfies the stem's misconfigured authentication default, escalating a network-reachable control plane port into node-wide container compromise.

Why this answer

The kubelet exposes an HTTP API on port 10250 that includes endpoints such as /exec, /run, and /attach. If authentication is disabled (e.g., --anonymous-auth=true with no authorization), an attacker on the pod network can call these endpoints directly to execute arbitrary commands inside any container running on that node. This bypasses the API server entirely and grants code execution with the container's privileges, often leading to node compromise.

Exam trap

KCSA often tests the misconception that the kubelet API is only for node management and cannot execute commands, leading candidates to overlook the exec/run endpoints as the primary threat vector.

How to eliminate wrong answers

Option B is wrong because etcd listens on port 2379/2380 and is not exposed by the kubelet; direct etcd modification requires access to the etcd cluster, not the kubelet API. Option C is wrong because image vulnerability scanners run in CI/CD pipelines and are not part of the Kubernetes control plane or kubelet API attack surface. Option D is wrong because TLS bootstrapping is a kubelet-to-API-server process for issuing client certificates, not a function of the kubelet API, and the API server does not issue root certificates via kubelet endpoints.

Full explanation →
175
MCQmedium

An organization wants to enforce that no containers run with privileged security contexts across multiple clusters. They implement admission control validation. In the context of cloud native security principles, what type of control is this?

A.Preventative automated policy control
B.Detective manual control
C.Corrective physical control
D.Compensating detective control
AnswerA

Admission control evaluates workloads before they are admitted, rejecting any pod whose securityContext sets privileged: true. Blocking non-compliant configurations prior to execution makes this a preventative automated policy control rather than a detective or reactive one.

Why this answer

Admission control validation in Kubernetes intercepts API requests before an object is persisted, and if the validating webhook rejects the request, the privileged pod is never created. This is a preventative control because it stops the non-compliant configuration from ever reaching the cluster, rather than detecting it after the fact. In cloud native security terms, it is automated (policy-as-code, e.g., OPA Gatekeeper or Kyverno) and preventative by design.

Exam trap

KCSA often tests the conflation of 'admission control' with 'detective' or 'corrective' controls — candidates who equate validation with monitoring pick detective, missing that blocking admission is inherently preventative.

How to eliminate wrong answers

Option B is wrong because a detective control observes and reports after the fact (e.g., audit logs, runtime scanning) and a manual control requires human intervention — admission validation is automated and blocks before persistence. Option C is wrong because 'corrective' implies remediating an existing violation and 'physical' refers to tangible controls like locks or guards, neither of which applies to a software admission webhook. Option D is wrong because 'compensating detective' describes an alternative monitoring control used when a primary control cannot be applied — admission validation is the primary preventative control itself, not a compensating detective one.

Full explanation →
176
MCQhard

An attacker with read access to Kubernetes Secrets inspects a secret containing TLS private keys. Under the STRIDE threat model, what specific threat category does this represent regarding confidentiality?

A.Denial of Service
B.Elevation of Privilege
C.Information Disclosure
D.Repudiation
AnswerC

Reading TLS private keys from a Secret exposes confidential data to an unauthorised party, which STRIDE classifies as Information Disclosure. The threat targets confidentiality directly, not integrity or availability, matching the stem's explicit confidentiality framing.

Why this answer

Information Disclosure is the STRIDE category that covers unauthorized access to confidential data, such as an attacker reading TLS private keys from a Kubernetes Secret. Since the attacker has read access to the secret, the confidentiality of the private keys is compromised, which is precisely Information Disclosure. This threat directly maps to the confidentiality pillar of security.

Exam trap

The trap is confusing Information Disclosure with Elevation of Privilege; candidates may think reading secrets is privilege escalation, but it is only escalation if the attacker uses the secret to gain higher permissions, whereas the act of reading is Information Disclosure.

How to eliminate wrong answers

Option A is wrong because Denial of Service involves disrupting availability, not reading secrets. Option B is wrong because Elevation of Privilege involves gaining higher permissions, not merely reading data the attacker already has access to. Option D is wrong because Repudiation involves denying actions, not data exposure.

Full explanation →
177
MCQeasy

An administrator wishes to inspect which admission controllers are currently enabled in a running Kubernetes cluster. Where is this typically configured in a stacked control plane?

A.In the kube-apiserver static pod manifest file under '/etc/kubernetes/manifests/kube-apiserver.yaml'.
B.In the CoreDNS deployment spec.
C.In the kubelet configuration file on each worker node.
D.In the cluster-wide ConfigMap named 'kube-system/cluster-admission'.
AnswerA

Admission controllers are enabled via the `--enable-admission-plugins` flag, which is passed to the kube-apiserver process. In a stacked control plane, the kube-apiserver runs as a static pod, so its flags live in the manifest at `/etc/kubernetes/manifests/kube-apiserver.yaml`. Inspecting that file reveals exactly which plugins are active.

Why this answer

In a kubeadm-provisioned stacked control plane, the kube-apiserver runs as a static pod, and its command-line flags — including --enable-admission-plugins and --disable-admission-plugins — are defined in /etc/kubernetes/manifests/kube-apiserver.yaml. Editing that manifest causes the kubelet to restart the apiserver pod with the new admission controller set.

Exam trap

KCSA often tests whether candidates know that admission controllers are configured as apiserver flags in the static pod manifest, not via ConfigMaps or kubelet config — a common misconception because many other Kubernetes settings are ConfigMap-driven.

How to eliminate wrong answers

Option B is wrong because CoreDNS is a cluster add-on Deployment that only handles DNS resolution; it has no role in configuring apiserver admission behavior. Option C is wrong because the kubelet config (e.g., /var/lib/kubelet/config.yaml) governs node-level behavior like cgroup driver and eviction thresholds, not apiserver admission plugins. Option D is wrong because there is no built-in ConfigMap named 'kube-system/cluster-admission' — admission plugin configuration is a static apiserver flag, not a runtime ConfigMap.

Full explanation →
178
Multi-Selectmedium

Which TWO of the following methods can be used to authenticate users or systems against the Kubernetes API server? (Choose TWO)

Select 2 answers
A.X.509 client certificates validated by the API server CA.
B.Unencrypted HTTP basic auth files with default passwords.
C.Anonymous packet sniffing via kube-proxy.
D.OpenID Connect (OIDC) tokens issued by an external identity provider.
E.Direct root SSH access to etcd nodes.
AnswersA, D

X.509 client certificates satisfy the stem's requirement for a native API server authentication method. The API server validates the certificate against its configured certificate authority, then maps the subject's common name to a user and organisation fields to groups. This operates without external identity providers, unlike OpenID Connect or webhook token authentication.

Why this answer

Option A is correct because the Kubernetes API server natively supports X.509 client certificate authentication: when a client presents a certificate signed by the cluster CA (configured via --client-ca-file), the API server validates it and maps the certificate's CN to a user and O to groups. Option D is correct because the API server can be configured with OIDC flags (--oidc-issuer-url, --oidc-client-id, --oidc-username-claim) to accept ID tokens issued by an external identity provider, authenticating users via the id_token JWT. Option B is wrong because basic auth with static password files is deprecated, disabled by default, and insecure, not a recommended authentication method.

Option C is wrong because kube-proxy handles service traffic routing, not authentication, and packet sniffing is not an authentication mechanism. Option E is wrong because SSH access to etcd nodes is infrastructure access, not an authentication method against the Kubernetes API server.

Exam trap

KCSA often tests whether candidates confuse authentication (who you are) with authorization (what you can do) or with infrastructure access — options like SSH to etcd or kube-proxy sniffing are distractors that sound security-related but have no role in API server authentication.

Full explanation →
179
Multi-Selectmedium

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

Select 2 answers
A.Validating admission webhooks can reject object definitions that violate security standards.
B.kubelet automatically runs security audits on all container images prior to pull.
C.etcd executes consensus validation scripts to strip unauthorized RBAC rules.
D.Mutating admission webhooks can alter request payloads to enforce defaults like securityContext constraints.
E.kube-proxy inspects network payloads at Layer 7 to block unauthorized API requests.
AnswersA, D

Validating admission webhooks run after mutation and evaluate the final object against policy, returning a denial that blocks persistence. This satisfies enforcement by rejecting non-compliant definitions outright, ensuring only objects meeting security standards reach etcd.

Why this answer

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.

Exam trap

KCSA often tests whether candidates confuse the admission phase (mutating vs validating webhooks) with unrelated components like kubelet, etcd, or kube-proxy — the trap is picking a plausible-sounding but architecturally wrong component for policy enforcement.

Full explanation →
180
MCQmedium

An application pod needs to mount a Secret as environment variables. Which section of the Pod manifest should be configured to achieve this securely?

A.Using 'env' with 'valueFrom.secretKeyRef' or 'envFrom' with 'secretRef' in the container specification.
B.Using 'volumeMounts' pointing to a PersistentVolumeClaim bound to the Secret.
C.Adding the Secret name directly to the container imagePullSecrets field.
D.Declaring the Secret in the container securityContext block.
AnswerA

Configuring `env` with `valueFrom.secretKeyRef`, or `envFrom` with `secretRef`, in the container specification injects Secret data as environment variables at pod start. This satisfies the stem's mount-as-environment-variables requirement without exposing the Secret through volumes, keeping credentials out of the manifest and node filesystem.

Why this answer

To expose a Secret as environment variables, you reference it in the container's env or envFrom block using valueFrom.secretKeyRef (for a single key) or envFrom.secretRef (for all keys). This is the standard, supported mechanism for injecting Secret data as environment variables in a Pod manifest.

Exam trap

The trap is confusing Secret consumption methods — candidates may pick volumeMounts or securityContext, but only env/envFrom with secretKeyRef or secretRef injects Secret data as environment variables.

How to eliminate wrong answers

Option B is wrong because PersistentVolumeClaims provide persistent storage volumes, not Secret data; Secrets are mounted via a secret volume source, not a PVC. Option C is wrong because imagePullSecrets is used only to authenticate to container registries when pulling images, not to inject application secrets as env vars. Option D is wrong because securityContext controls Linux security settings (runAsUser, capabilities, seccomp), not environment variable injection from Secrets.

Full explanation →
181
Multi-Selecthard

Which THREE of the following components are typically the responsibility of the user (rather than the cloud provider) in a managed Kubernetes service (like EKS, GKE, or AKS) under the shared responsibility model?

Select 3 answers
A.Implementing container image vulnerability management and hardening base images.
B.Manufacturing the physical hardware and server racks in the data center.
C.Configuring Kubernetes RBAC roles and role bindings.
D.Writing secure application code and managing third-party dependencies.
E.Applying security patches to the managed cloud control plane master nodes.
AnswersA, C, D

Managed services patch the control plane and node OS, but image contents are tenant-supplied. Scanning images and hardening base images therefore remain customer duties, since the provider cannot inspect or rebuild artefacts pushed to the cluster's registries.

Why this answer

In a managed Kubernetes service, the cloud provider secures the managed control plane, while the customer remains responsible for what runs on and is configured within the cluster. Option A is correct because container image vulnerability management and base-image hardening are customer duties: you must scan images (e.g., with Trivy or ECR scanning) and build minimal, patched images, since the provider does not control your image supply chain. Option C is correct because Kubernetes RBAC roles and role bindings are cluster-level authorization objects that the user defines and maintains to enforce least privilege; the provider only secures the API server infrastructure, not your authorization policy.

Option D is correct because writing secure application code and managing third-party dependencies (libraries, CVEs, SBOMs) is entirely the customer's responsibility, as the provider has no visibility into or control over your application logic and packages. Option B is not correct because manufacturing physical hardware and server racks is the cloud provider's responsibility, not the user's. Option E is not correct because patching the managed control plane master nodes is handled by the cloud provider in EKS, GKE, and AKS under the shared responsibility model.

Exam trap

KCSA often tests the boundary of the shared responsibility model — candidates incorrectly assume 'managed' means the provider handles RBAC, image scanning, or app security, when in fact those remain customer responsibilities.

Full explanation →
182
MCQeasy

Which Kubernetes control plane component runs controllers that handle routine tasks such as replicating pods and managing service accounts?

A.CoreDNS
B.kube-controller-manager
C.etcd
D.kube-proxy
AnswerB

kube-controller-manager runs the built-in controllers, including the ReplicaSet controller that maintains desired pod counts and the service account controller that creates default tokens. It satisfies the stem's requirement for routine replication and service account management.

Why this answer

The kube-controller-manager is the control plane component that runs the built-in controllers — including the ReplicaSet controller (which maintains desired pod replica counts), the ServiceAccount controller (which creates default service accounts and tokens), and the Node, Endpoint, and Namespace controllers. It continuously reconciles observed cluster state with the desired state declared in the API server.

Exam trap

KCSA often tests component-role confusion — candidates mix up etcd (storage), kube-proxy (networking), and kube-controller-manager (reconciliation), picking the component that 'sounds' like it manages things.

How to eliminate wrong answers

Option A is wrong because CoreDNS is a cluster DNS add-on that resolves service names to ClusterIPs; it performs no controller reconciliation. Option C is wrong because etcd is the distributed key-value store that persists all cluster state — it stores data but does not run controllers. Option D is wrong because kube-proxy is a per-node network component that implements Service load balancing via iptables/IPVS rules, not a control plane controller.

Full explanation →
183
Multi-Selectmedium

Which THREE of the following tasks are performed by the Kubernetes control plane's kube-controller-manager? (Choose THREE)

Select 3 answers
A.Managing node lifecycle status and detecting node failures.
B.Maintaining desired pod replica counts via ReplicaSets.
C.Running container workloads directly on worker node operating systems.
D.Generating and managing ServiceAccount tokens and default namespace tokens.
E.Configuring iptables and IPVS rules for Kubernetes Services on nodes.
AnswersA, B, D

The node controller within kube-controller-manager monitors node health, applies taints and evicts Pods when nodes become unreachable. This node lifecycle and failure detection duty is one of its core responsibilities, matching the stem's requested control plane task.

Why this answer

The kube-controller-manager runs a set of control loops, and among them the node lifecycle controller (A) monitors node health, applies taints like node.kubernetes.io/not-ready, and detects node failures, which is exactly the node lifecycle status management described. The ReplicaSet controller (B) is a core controller inside kube-controller-manager that continuously reconciles the actual number of pod replicas with the desired count specified in a ReplicaSet, so it maintains desired pod replica counts. The ServiceAccount and token controllers (D) are also part of kube-controller-manager; they create default ServiceAccounts and generate/manage ServiceAccount tokens (and the default namespace token) for pods to authenticate to the API server.

Option C is wrong because running container workloads on worker nodes is the job of the kubelet and container runtime (e.g., containerd/CRI-O), not the control plane. Option E is wrong because iptables/IPVS rules for Services are programmed by kube-proxy on each node, not by kube-controller-manager.

Exam trap

KCSA often tests the division of responsibilities between control plane components, and candidates may incorrectly attribute node-level networking (kube-proxy) or container execution (kubelet/CRI) to the kube-controller-manager.

Full explanation →
184
MCQmedium

An Ingress controller is deployed in a cluster, and security auditors request that incoming traffic must be restricted to specific trusted external CIDR blocks. Which standard Ingress annotation is commonly supported by popular Ingress controllers (such as ingress-nginx) to achieve IP-based allowlisting?

A.ingress.kubernetes.io/allowed-source-cidrs
B.networking.k8s.io/ip-filter
C.nginx.ingress.kubernetes.io/whitelist-source-range
D.kubernetes.io/ingress.allow-ips
AnswerC

The whitelist-source-range annotation accepts a comma-separated list of trusted CIDR blocks, and ingress-nginx enforces it at the controller by rejecting requests whose source IP falls outside those ranges, directly satisfying the auditors' requirement to restrict incoming traffic to specific external networks.

Why this answer

The ingress-nginx controller supports the annotation nginx.ingress.kubernetes.io/whitelist-source-range, which accepts a comma-separated list of CIDR blocks. When set, the controller's NGINX configuration adds allow/deny directives so that only requests originating from those CIDRs are permitted; all other source IPs receive a 403. This is the standard, documented mechanism for IP allowlisting at the Ingress layer in ingress-nginx.

Exam trap

KCSA often tests whether candidates know the exact annotation namespace and syntax for ingress-nginx, baiting them with plausible-looking but non-existent annotations that mix API group names with feature descriptions.

How to eliminate wrong answers

Option A is wrong because ingress.kubernetes.io/allowed-source-cidrs is not a recognized annotation in ingress-nginx or other mainstream controllers — it resembles a plausible but fabricated name. Option B is wrong because networking.k8s.io/ip-filter is not a valid Ingress annotation; the networking.k8s.io API group is used for Ingress resource fields, not for this filtering feature. Option D is wrong because kubernetes.io/ingress.allow-ips is not a real annotation — kubernetes.io annotations exist for other purposes (e.g., ingress.class), but not for source IP allowlisting.

Full explanation →
185
Multi-Selecteasy

Which TWO of the following are core security hardening best practices for the Kubernetes API server? (Choose TWO)

Select 2 answers
A.Ensure the insecure port (--insecure-port) is disabled or set to 0.
B.Configure the API server to use HTTP instead of HTTPS for performance.
C.Store all kubeconfig credentials in public ConfigMaps.
D.Grant cluster-admin permissions to all authenticated users by default.
E.Disable anonymous authentication by setting --anonymous-auth=false.
AnswersA, E

Disabling `--insecure-port` closes the unauthenticated, unencrypted HTTP listener that otherwise bypasses TLS and authentication entirely, exposing the API server to anonymous requests. Setting it to 0 satisfies the hardening requirement by forcing all traffic through the secure port, where authentication and authorisation controls apply.

Why this answer

Option A is correct because the API server's insecure port (--insecure-port) serves unauthenticated, unencrypted HTTP traffic, so setting it to 0 (or disabling it) is a fundamental CIS Kubernetes Benchmark hardening step that forces all communication through the authenticated, TLS-protected secure port (default 6443). Option E is correct because anonymous authentication allows unauthenticated requests to reach the API server and be evaluated as the system:anonymous user; setting --anonymous-auth=false ensures every request must present valid credentials, preventing unauthenticated access and information disclosure. Option B is wrong because HTTP would remove TLS encryption and client authentication, weakening rather than hardening the API server.

Option C is wrong because kubeconfig files contain credentials and certificates, and storing them in public ConfigMaps would expose cluster access to anyone who can read the ConfigMap. Option D is wrong because granting cluster-admin to all authenticated users violates least privilege and would give every account full control of the cluster.

Exam trap

KCSA often tests whether candidates know that anonymous auth and the insecure port are separate controls — the trap is picking only one or confusing them with authorization settings like RBAC, when both authentication-layer flags must be disabled for a hardened API server.

Full explanation →
186
MCQmedium

An attacker compromises a cluster node and attempts to inspect container communication. By default, how is pod-to-pod network traffic handled across different nodes in a standard Kubernetes cluster without a service mesh or CNI encryption enabled?

A.Encrypted automatically using mandatory 256-bit AES transport layer security
B.Blocked entirely by default unless a LoadBalancer service is declared
C.Routed exclusively through the etcd secure TLS database tunnel
D.Transmitted in plain text across the network fabric, making it vulnerable to sniffing
AnswerD

Plain text transmission occurs because Kubernetes delegates pod networking to the CNI plugin, and without encryption enabled, packets traverse the network fabric unencrypted. The compromised node can therefore sniff inter-node pod traffic directly, satisfying the stem's constraint of no service mesh or CNI encryption.

Why this answer

In a standard Kubernetes cluster, pod-to-pod traffic across nodes is not encrypted by default. The CNI plugin (e.g., Calico, Flannel, Cilium) is responsible for routing packets between nodes, but unless a feature like WireGuard, IPsec, or a service mesh (e.g., Istio with mTLS) is explicitly enabled, the packets are sent in plain text over the network fabric. This means an attacker who has compromised a node and can sniff network traffic can potentially capture sensitive data exchanged between pods.

Exam trap

KCSA often tests the misconception that Kubernetes encrypts pod-to-pod traffic by default, confusing the secure control plane (etcd, API server) with the data plane, or assuming that CNI plugins provide encryption out of the box.

How to eliminate wrong answers

Option A is wrong because Kubernetes does not automatically encrypt pod-to-pod traffic with AES; encryption requires explicit configuration of a CNI with encryption or a service mesh. Option B is wrong because pod-to-pod communication is allowed by default; NetworkPolicies can restrict it, but they are not enabled by default, and LoadBalancer services are for external access, not for enabling internal pod traffic. Option C is wrong because etcd is the cluster's key-value store and is not involved in pod-to-pod data plane traffic; etcd communication is secured with TLS, but that is separate from pod networking.

Full explanation →
187
MCQmedium

An organization's security team mandates that all Kubernetes worker nodes must be scanned for Common Vulnerabilities and Exposures (CVEs) on a scheduled basis. Under the 4Cs, what layer does node vulnerability scanning address?

A.Container layer
B.Cloud layer
C.Cluster layer
D.Code layer
AnswerC

Node CVE scanning targets the operating system, kernel and runtime packages of the worker nodes themselves, which sit in the Cluster layer of the 4Cs; it does not address application code, container image contents or cloud provider infrastructure.

Why this answer

Under the 4Cs (Cloud, Cluster, Container, Code), the cluster layer encompasses the control plane components, worker nodes, kubelet, container runtime, and node OS. Scanning worker nodes for CVEs addresses vulnerabilities in the node operating system, kernel, and installed packages — squarely a cluster-layer concern. This is distinct from scanning container images (container layer) or application source (code layer).

Exam trap

KCSA often tests whether candidates can correctly map a security activity to the right C of the 4Cs, tempting them to pick 'Container' whenever containers or Kubernetes are mentioned, even when the target is the node OS itself.

How to eliminate wrong answers

Option A is wrong because the container layer covers the container image contents, base image packages, and runtime configuration — not the underlying node OS. Option B is wrong because the cloud layer refers to the cloud provider's infrastructure, IAM, network controls, and managed service configuration, not node-level OS patching. Option D is wrong because the code layer addresses application source code, dependencies, and CI/CD pipeline security, not host-level vulnerabilities.

Full explanation →
188
MCQhard

A healthcare company is designing a new cloud native platform and wants to apply the principle that no single security control should be the sole barrier protecting a critical asset. Their architects propose encrypting data at rest and relying on that encryption as the primary defense against unauthorized database access by a compromised pod. Which design change best reflects the intended principle?

A.Add network policies, workload identity with scoped RBAC, and runtime detection so that encryption is one layer among several independent controls.
B.Move the database to a private subnet and remove its public endpoint, treating network isolation as the replacement for all other controls.
C.Store the encryption keys in the same namespace as the application so that pods can retrieve them quickly and avoid external key management latency.
D.Increase the encryption key length and rotate keys more frequently so that brute-force decryption of the storage volume becomes computationally infeasible.
AnswerA

This correctly implements defense in depth. Encryption at rest protects stored bytes, but a compromised pod using valid credentials can still read decrypted data through the database API. Layering network segmentation, least-privilege identity, and runtime detection creates independent barriers so no single failure exposes the asset.

Why this answer

Defense in depth assumes any single control can fail or be bypassed, so critical assets need multiple independent barriers. Encryption at rest only protects stored bytes; a pod with valid credentials reads decrypted data normally. Adding segmentation, scoped workload identity, and runtime detection ensures a compromise of one mechanism does not directly expose the asset.

Exam trap

The trap here is treating stronger encryption of one layer as equivalent to adding independent layers of defense.

Full explanation →
189
MCQmedium

Your team is implementing image caching and proxying to protect against external container registry rate limits and security incidents. Which upstream project acts as a CNCF-compliant registry proxy and caching mechanism?

A.Harbor
B.Fluentd
C.Jaeger
D.Prometheus
AnswerA

Harbor is the CNCF-graduated registry that provides proxy caching, pulling and storing upstream images locally. This satisfies the requirement to shield clusters from external registry rate limits while enabling vulnerability scanning and policy enforcement on cached artefacts.

Why this answer

Harbor is a CNCF-graduated project that provides a container image registry with a built-in proxy cache. It can be configured to proxy and cache images from external registries like Docker Hub, mitigating rate limits and ensuring a local copy for security scanning. This makes it the correct answer for a CNCF-compliant registry proxy and caching mechanism.

Exam trap

KCSA often tests the distinction between CNCF projects and their primary functions; candidates may confuse monitoring (Prometheus) or logging (Fluentd) tools with registry solutions, but Harbor is the only registry-focused project among the options.

How to eliminate wrong answers

Option B is wrong because Fluentd is a log collector and processor, not a container registry proxy or cache. Option C is wrong because Jaeger is a distributed tracing system, unrelated to image caching. Option D is wrong because Prometheus is a monitoring and alerting toolkit, not a registry proxy.

Full explanation →
190
Multi-Selecteasy

Which TWO components are core parts of the Kubernetes authorization architecture? (Choose TWO)

Select 2 answers
A.Webhook Authorization
B.Role-Based Access Control (RBAC)
C.CoreDNS service discovery
D.Kubelet node daemon
E.etcd key-value datastore
AnswersA, B

Webhook authorization is a core Kubernetes authorization module, letting the API server delegate access decisions to an external HTTP service. It satisfies the requirement for pluggable, policy-driven decisions, integrating with external engines such as Open Policy Agent or Microsoft Entra ID-based tooling without rebuilding the API server.

Why this answer

Webhook Authorization (A) is a core Kubernetes authorization mode that lets the API server send SubjectAccessReview requests to an external HTTP service to decide whether a request is allowed, and it is one of the standard authorization modes configured via --authorization-mode. Role-Based Access Control (B) is also a core authorization component: it uses RBAC API objects such as Roles, ClusterRoles, RoleBindings, and ClusterRoleBindings to grant permissions to users, groups, and ServiceAccounts, and is enabled as an authorization mode on the kube-apiserver. CoreDNS service discovery (C) is a cluster DNS add-on for name resolution, not an authorization mechanism.

Kubelet (D) is the node agent that manages pods and containers, and etcd (E) is the key-value datastore backing cluster state; neither performs authorization decisions for API requests.

Exam trap

The trap here is confusing cluster infrastructure components (like CoreDNS, kubelet, etcd) with authorization mechanisms; candidates might assume any core Kubernetes component plays a role in authorization, but only modules that directly evaluate access requests are part of the authorization architecture.

Full explanation →
191
MCQhard

You need to audit the cryptographic algorithms and TLS versions permitted by the Kubernetes API server for incoming client connections. Which API server flag enforces a minimum TLS version of 1.3?

A.--min-tls=1.3
B.--tls-min-version=VersionTLS13
C.--cipher-suites=TLS_AES_256_GCM_SHA384
D.--ssl-version=TLSv3
AnswerB

The --tls-min-version flag directly sets the floor for negotiated TLS versions on the API server's secure port. Specifying VersionTLS13 rejects any client offering TLS 1.2 or lower, satisfying the audit requirement to enforce TLS 1.3 as the minimum permitted version.

Why this answer

The kube-apiserver flag `--tls-min-version` sets the minimum TLS version accepted for incoming client connections. To enforce TLS 1.3, the value must be `VersionTLS13` (the Go constant used by the API server). This flag is part of the secure serving options and is critical for compliance with modern cryptographic standards.

Exam trap

KCSA often tests the exact flag name and value syntax for TLS version enforcement, with distractors using plausible but invalid flags like `--min-tls` or `--ssl-version`.

How to eliminate wrong answers

Option A is wrong because `--min-tls` is not a valid kube-apiserver flag; the correct flag is `--tls-min-version`. Option C is wrong because `--cipher-suites` specifies allowed cipher suites, not the TLS version; also, TLS 1.3 cipher suites are not configurable via this flag in Go. Option D is wrong because `--ssl-version` is not a valid flag, and 'TLSv3' is not a real TLS version (TLS 1.3 is the latest).

Full explanation →
192
MCQhard

You are reviewing security logs on a control plane node and discover that an unauthenticated user accessed the kubelet's HTTPS port (10250) to execute commands inside containers. How should you restrict kubelet authentication and authorization to prevent this?

A.Enable the kubelet insecure-port flag.
B.Set authorization.mode: AlwaysAllow in the kubelet configuration file.
C.Disable the API server proxy subresource.
D.Set authentication.anonymous.enabled: false and authorization.mode: Webhook in the kubelet configuration file.
AnswerD

Disabling anonymous authentication forces credentials on port 10250, and Webhook authorization delegates each request to the API server's RBAC evaluation. Together they eliminate unauthenticated command execution, satisfying the stem's requirement to restrict both kubelet authentication and authorization.

Why this answer

Setting authentication.anonymous.enabled to false disables unauthenticated access to the kubelet, and setting authorization.mode to Webhook delegates authorization decisions to the API server, which enforces RBAC. This combination ensures that only authenticated and authorized requests can execute commands via the kubelet, preventing the observed unauthenticated access.

Exam trap

The trap is that candidates may think disabling the API server proxy subresource (option C) secures the kubelet, but the kubelet's HTTPS port is directly accessible and must be secured independently.

How to eliminate wrong answers

Option A is wrong because enabling the kubelet insecure-port flag (or leaving it enabled) exposes an unauthenticated HTTP endpoint, which is the opposite of restricting access. Option B is wrong because authorization.mode: AlwaysAllow permits all requests without any authorization checks, which would allow the unauthenticated access to continue. Option C is wrong because disabling the API server proxy subresource does not affect direct access to the kubelet's HTTPS port; it only blocks the API server's proxy functionality, leaving the kubelet exposed.

Full explanation →
193
Multi-Selectmedium

Which THREE of the following practices should be implemented to secure etcd in a production Kubernetes deployment? (Choose THREE)

Select 3 answers
A.Disable TLS verification to simplify certificate rotation.
B.Enable client certificate authentication using --client-cert-auth=true.
C.Expose etcd on a public internet IP address without authentication for easy monitoring.
D.Encrypt data at rest in etcd using an EncryptionConfiguration file.
E.Enable peer-to-peer encryption and mutual TLS using peer certificate flags.
AnswersB, D, E

Enabling `--client-cert-auth=true` forces every etcd client to present a certificate signed by the trusted CA, blocking unauthenticated access to the datastore. This satisfies the stem's requirement to secure etcd by ensuring only verified API server and operator identities can read or write cluster state.

Why this answer

Option B is correct because enabling client certificate authentication with --client-cert-auth=true forces every etcd client (kube-apiserver, etcdctl, etc.) to present a valid TLS client certificate signed by the trusted CA, preventing unauthenticated access to the etcd API. Option D is correct because encrypting data at rest via an EncryptionConfiguration file (referenced with --encryption-provider-config) protects Secrets and other sensitive objects stored in etcd from being read in plaintext if the disk or backup is compromised. Option E is correct because etcd peer traffic carries cluster state and raft data, so enabling peer-to-peer encryption with mutual TLS using flags such as --peer-cert-file, --peer-key-file, --peer-trusted-ca-file, and --peer-client-cert-auth=true ensures only authenticated cluster members can exchange data.

Option A is not acceptable because disabling TLS verification (e.g., --insecure-skip-tls-verify) removes server identity validation and exposes etcd to man-in-the-middle attacks, and option C is not acceptable because exposing etcd on a public IP without authentication allows anyone to read or modify the entire cluster's state.

Exam trap

KCSA often tests whether candidates recognize that 'disable TLS verification' and 'expose etcd publicly' are always wrong, while the correct trio combines client cert auth, encryption at rest, and peer mTLS — a classic 'choose three' pattern.

Full explanation →
194
MCQmedium

A security engineer discovers that an attacker has gained access to a container and is attempting to modify container files in a way that persists across pod restarts if the container image is faulty. However, the root filesystem is marked as readOnlyRootFilesystem: true. What is the impact of this setting on the attack?

A.It enforces TLS encryption for all outbound pod network connections.
B.It mitigates threats by preventing attackers from writing malicious binaries or modifying system files in the root filesystem.
C.It automatically encrypts all environment variables stored in the Pod spec.
D.It completely prevents any container from starting up if PersistentVolumeClaims are attached.
AnswerB

Setting `readOnlyRootFilesystem: true` mounts the container's root filesystem as a read-only layer, so any write attempt by the attacker fails with a filesystem error. This directly satisfies the stem's constraint: malicious binaries or modified system files cannot be written, blocking persistence across pod restarts.

Why this answer

Setting readOnlyRootFilesystem: true mounts the container's root filesystem as read-only, which prevents an attacker from writing malicious binaries or modifying system files in the root filesystem. This directly mitigates the threat of persistent modifications to the container image or filesystem. The setting does not affect network encryption, environment variables, or PVC attachment.

Exam trap

The trap is assuming readOnlyRootFilesystem prevents all writes; candidates may forget that writable volumes can still be mounted, or confuse it with unrelated controls like TLS encryption or environment variable protection.

How to eliminate wrong answers

Option A is wrong because readOnlyRootFilesystem has no effect on TLS encryption for outbound connections; TLS is configured at the application or service mesh level. Option C is wrong because environment variables are not encrypted by this setting; they are stored in the Pod spec and can be exposed via the API. Option D is wrong because readOnlyRootFilesystem does not prevent container startup with PVCs; PVCs are mounted as separate volumes and can be writable even if the root filesystem is read-only.

Full explanation →
195
MCQhard

A security engineer configures a ValidatingWebhookConfiguration to intercept pod creations. The webhook service goes down due to a network partition. What happens to incoming pod creation requests by default if the webhook 'failurePolicy' is set to 'Fail'?

A.The kubelet automatically bypasses the webhook and starts the container locally.
B.The API server allows the pod creation request and logs a warning.
C.The API server rejects the pod creation request with an error.
D.The API server queues the request until the webhook service recovers.
AnswerC

Under failurePolicy: Fail, a webhook call that cannot complete because of the network partition is treated as a failed admission decision, so the API server denies the request and returns an error to the client rather than admitting the pod.

Why this answer

When a ValidatingWebhookConfiguration has failurePolicy: Fail, the API server treats a webhook call failure (timeout, connection refused, network partition) as a denial and rejects the admission request with an error. This is the safe default for security-critical webhooks because it prevents unvalidated resources from being admitted during an outage.

Exam trap

KCSA often tests the inversion of failurePolicy semantics — candidates assume 'Fail' means 'fail open' or that the API server retries, when in fact Fail means the request is rejected immediately with no retry.

How to eliminate wrong answers

Option A is wrong because kubelet does not participate in admission control — admission webhooks are invoked by the kube-apiserver before the object is persisted to etcd, so kubelet never sees the pod if admission fails. Option B is wrong because that describes failurePolicy: Ignore, which allows the request through on webhook failure; with Fail, the request is rejected. Option D is wrong because the API server does not queue admission requests for retry — it applies the failurePolicy immediately (reject or allow) and returns the result to the client.

Full explanation →
196
Multi-Selectmedium

Which THREE conditions must be met for a RoleBinding to successfully grant permissions to a ServiceAccount?

Select 3 answers
A.The kubelet must restart to load the binding.
B.The RoleBinding and Role must reside in the same namespace (if using a Role).
C.The RoleBinding must reference an existing Role or ClusterRole.
D.The ServiceAccount must have cluster-admin privileges.
E.The ServiceAccount subject must be correctly specified with its name and namespace.
AnswersB, C, E

A Role is namespaced, and a RoleBinding can only grant permissions defined within its own namespace. If the binding and Role sit in different namespaces, the reference cannot resolve, so co-location is required when binding to a Role rather than a ClusterRole.

Why this answer

Option B is correct because a Role is a namespaced resource, so a RoleBinding can only bind to a Role that exists in the same namespace as the RoleBinding; cross-namespace Role references are not permitted. Option C is correct because the RoleBinding's roleRef must point to a Role or ClusterRole that actually exists, otherwise the binding grants nothing and the API server rejects or the reference is invalid. Option E is correct because the subject entry for a ServiceAccount must include both the ServiceAccount name and its namespace (kind: ServiceAccount, name, namespace), since ServiceAccounts are namespaced identities and an incomplete subject will not match the intended account.

Option A is wrong because RBAC bindings are evaluated dynamically by the API server at request time and require no kubelet restart. Option D is wrong because granting permissions via a RoleBinding does not require the ServiceAccount to hold cluster-admin; the binding itself supplies the permissions, and cluster-admin is unrelated to the binding mechanics.

Exam trap

The trap is the misconception that RBAC changes require a component restart or elevated privileges, when in fact RoleBindings take effect immediately and only need an existing Role/ClusterRole plus a correctly namespaced subject.

Full explanation →
197
Multi-Selectmedium

Which THREE of the following represent security risks or anti-patterns in cloud native application design? (Choose THREE)

Select 3 answers
A.Exposing the Kubernetes dashboard or debug endpoints publicly without authentication
B.Implementing automated vulnerability scanning in CI/CD pipelines
C.Using immutable infrastructure principles for cluster worker nodes
D.Running container processes with root user IDs inside the container
E.Storing sensitive API keys and database passwords in plain text within Kubernetes ConfigMaps
AnswersA, D, E

An unauthenticated Kubernetes dashboard or debug endpoint grants direct cluster control, enabling workload creation, secret retrieval and privilege escalation. Exposing these interfaces publicly removes the authentication boundary the API server otherwise enforces, making them a recognised cloud native anti-pattern.

Why this answer

Option A is correct because exposing the Kubernetes dashboard or debug endpoints (e.g., /debug/pprof, actuator endpoints) to the public internet without authentication gives attackers an unauthenticated administrative or diagnostic interface, enabling cluster takeover or information disclosure. Option D is correct because running container processes as UID 0 (root) violates least privilege; if an attacker escapes or exploits the container, root inside the container eases privilege escalation, host filesystem access via mounted volumes, and bypassing of Pod Security Standards such as restricted policies requiring runAsNonRoot. Option E is correct because Kubernetes ConfigMaps store data as plaintext in etcd and are not designed for secrets; API keys and database passwords placed there are readable by anyone with get/list on ConfigMaps and are exposed in backups and manifests, so Secrets (ideally with encryption at rest and external KMS/vault integration) should be used instead.

Option B does not belong because automated vulnerability scanning in CI/CD pipelines is a security best practice that detects known CVEs early, not a risk or anti-pattern. Option C does not belong because immutable infrastructure for cluster worker nodes is a recommended pattern that reduces configuration drift and limits persistent attacker footholds, not a security risk.

Exam trap

KCSA often tests whether candidates can distinguish security best practices from anti-patterns; the trap is selecting options that sound security-related (like scanning or immutable infrastructure) as risks when they are actually controls.

Full explanation →
198
MCQmedium

A security engineer is hardening a Kubernetes cluster and wants to ensure that all container images are pulled only from an approved internal container registry (e.g., registry.internal.corp). Which Kubernetes mechanism can enforce this restriction across all namespaces?

A.Deploying a validating admission policy or webhook to check image registry URLs
B.Configuring NodePort service selectors
C.Enabling horizontal pod autoscaling
D.Modifying the kube-proxy IPVS configuration
AnswerA

A validating admission policy or webhook intercepts pod creation requests before persistence, rejecting any container image whose registry URL is not registry.internal.corp. Because admission control operates at the API server level, it applies cluster-wide across all namespaces, satisfying the requirement to enforce the approved internal registry restriction.

Why this answer

A validating admission policy or webhook is the correct mechanism because Kubernetes admission controllers intercept API requests before objects are persisted, allowing enforcement of image registry restrictions cluster-wide. Tools like OPA Gatekeeper, Kyverno, or the built-in ValidatingAdmissionPolicy (K8s 1.26+) can reject any Pod whose image field does not match an approved registry prefix such as registry.internal.corp. This enforcement applies across all namespaces without modifying individual workloads.

Exam trap

KCSA often tests whether candidates confuse admission control (policy enforcement at API level) with networking or scaling mechanisms, so they pick NodePort or HPA options that sound cluster-wide but do not inspect image fields.

How to eliminate wrong answers

Option B is wrong because NodePort service selectors control how Services expose pods on node ports — they have no role in validating container image sources. Option C is wrong because Horizontal Pod Autoscaling adjusts replica counts based on metrics; it does not inspect or restrict image origins. Option D is wrong because kube-proxy IPVS configuration governs service load-balancing behavior at the network layer, not admission-time policy enforcement on Pod specs.

Full explanation →
199
Multi-Selectmedium

Which THREE of the following practices should be followed when configuring Kubernetes audit logging? (Choose THREE)

Select 3 answers
A.Store audit logs in unencrypted public ConfigMaps.
B.Disable audit logging entirely to maximize API server performance.
C.Monitor audit logs regularly for suspicious authentication failures or privilege escalations.
D.Store audit logs in a secure location with restricted file permissions on the host or ship them to a SIEM.
E.Define an explicit audit policy file detailing which log levels and events to capture.
AnswersC, D, E

Regular monitoring of audit logs detects suspicious authentication failures and privilege escalations, turning recorded events into actionable security signal. This satisfies the practice requirement because collecting audit data without review provides no detection value; anomalies must be identified and investigated promptly.

Why this answer

Option C is correct because Kubernetes audit logs record authentication attempts, RBAC authorization decisions, and privileged operations, so regularly monitoring them is essential to detect brute-force authentication failures, unauthorized privilege escalations, and anomalous API activity. Option D is correct because audit logs can contain sensitive data such as request bodies, tokens, and Secret contents, so they must be written to a protected location with restricted file permissions (for example, a log file readable only by root) or forwarded to a centralized SIEM with appropriate access controls and retention. Option E is correct because audit logging is driven by an audit policy file passed to the kube-apiserver via --audit-policy-file, which explicitly defines rules with levels such as None, Metadata, Request, and RequestResponse and specifies which resources, verbs, and namespaces are captured.

Option A is not appropriate because ConfigMaps are not a secure or intended storage mechanism for audit logs and exposing them unencrypted publicly would leak sensitive cluster data. Option B is not appropriate because disabling audit logging removes the accountability and forensic trail needed for security monitoring and compliance, and audit logging can be tuned via policy levels rather than turned off entirely.

Exam trap

KCSA often tests the trade-off between performance and security — candidates pick 'disable logging' for speed or 'store in ConfigMaps' for convenience, missing that audit logs are sensitive and mandatory for compliance.

Full explanation →
200
Multi-Selecthard

Which THREE of the following capabilities or runtime configurations pose extreme risks of container escape when granted to an untrusted workload?

Select 3 answers
A.`hostPID: true` sharing the host process namespace
B.Setting `automountServiceAccountToken: false` on the service account
C.`securityContext.privileged: true`
D.Granting the `CAP_SYS_ADMIN` capability in the container security context
E.Setting `readOnlyRootFilesystem: true` in the container specification
AnswersA, C, D

Sharing the host PID namespace lets the container see and signal host processes, enabling escape via tools like nsenter into host namespaces. It directly satisfies the extreme-risk container escape criterion by removing process isolation between workload and node.

Why this answer

Option A (`hostPID: true`) is correct because sharing the host PID namespace lets the container see and signal host processes, enabling attacks such as ptrace-based injection into host daemons or killing host security agents, which is a classic container-escape vector. Option C (`securityContext.privileged: true`) is correct because a privileged container disables most isolation: it gets all Linux capabilities, access to all host devices, and relaxed seccomp/AppArmor confinement, so it can mount the host filesystem or load kernel modules to break out. Option D (granting `CAP_SYS_ADMIN`) is correct because this capability permits mount operations, namespace manipulation, and other kernel-level actions that allow escaping the container boundary even without full privileged mode.

Option B (`automountServiceAccountToken: false`) is not a risk — it reduces exposure by preventing the pod from receiving a Kubernetes API token. Option E (`readOnlyRootFilesystem: true`) is a hardening measure that makes the container's root filesystem immutable and does not enable escape.

Exam trap

KCSA often tests the misconception that any securityContext setting that sounds restrictive (like readOnlyRootFilesystem or automountServiceAccountToken: false) is risky, when in fact they are hardening measures; the real dangers are permissive settings like hostPID, privileged, and CAP_SYS_ADMIN.

Full explanation →
201
Multi-Selecteasy

Which TWO of the following tasks are handled by the kube-scheduler? (Choose TWO)

Select 2 answers
A.Generating X.509 client certificates for cluster bootstrapping.
B.Evaluating pending pods and selecting suitable worker nodes for placement.
C.Respecting node taints, tolerations, and affinity rules during scheduling.
D.Managing encryption keys inside the etcd database.
E.Executing container liveness probes inside running pods.
AnswersB, C

Evaluating pending pods and selecting suitable worker nodes is precisely the kube-scheduler's binding decision: it filters nodes via predicates, then ranks feasible ones by priority to satisfy resource requests, affinity and taints. This directly fulfils the stem's scheduling constraint, unlike controllers that merely create pods or kubelets that run them.

Why this answer

Option B is correct because the kube-scheduler's core function is to watch for newly created Pods that have no node assigned (Pending) and select a suitable node for them via its scheduling cycle. Option C is correct because during that scheduling cycle the kube-scheduler applies filtering and scoring predicates that include node taints/tolerations and node/pod affinity and anti-affinity rules to pick the best fit. Option A is not a scheduler task: X.509 client certificates for bootstrapping are issued by the kubelet's TLS bootstrap process via the CSR API and controller-manager signers.

Option D is not a scheduler task: etcd encryption keys are managed through the kube-apiserver's EncryptionConfiguration and kube-controller-manager, not the scheduler. Option E is not a scheduler task: liveness probes are executed by the kubelet on each node, not by the scheduler.

Exam trap

KCSA often tests the confusion between kube-scheduler and kubelet responsibilities, tricking candidates into selecting tasks like probe execution or certificate generation that belong to other components.

Full explanation →
202
Multi-Selectmedium

A cluster administrator is conducting a threat analysis regarding supply chain vulnerabilities in container registries and deployment pipelines. Which TWO of the following practices directly mitigate supply chain threats in Kubernetes? (Choose TWO)

Select 2 answers
A.Increasing the CPU limits on all worker nodes to handle larger container images
B.Enforcing cryptographic image signing and verification using tools like Sigstore Cosign
C.Configuring static IP addresses for all worker nodes in the private subnet
D.Integrating automated vulnerability scanning into the CI/CD pipeline before pushing images to the registry
E.Disabling the default token automount on all namespaces globally
AnswersB, D

Cryptographic signing with Sigstore Cosign attaches verifiable signatures to container images, and admission controllers reject unsigned or tampered images. This enforces provenance and integrity at deploy time, directly blocking the registry and pipeline tampering that supply chain attacks exploit.

Why this answer

Option B is correct because enforcing cryptographic image signing and verification with tools like Sigstore Cosign ensures that only images signed by trusted publishers can be admitted and run in the cluster, directly preventing tampered or malicious images from entering the supply chain. Option D is correct because integrating automated vulnerability scanning into the CI/CD pipeline before images are pushed to the registry catches known CVEs and misconfigurations at build time, stopping vulnerable artifacts from ever reaching production. Option A is incorrect because CPU limits on worker nodes have no bearing on supply chain integrity; they only affect resource scheduling and performance.

Option C is incorrect because static IP addresses for worker nodes address network stability and routing, not the authenticity or integrity of container images. Option E is incorrect because disabling the default service account token automount reduces the blast radius of a compromised pod's API credentials, but it does not mitigate supply chain threats such as image tampering or vulnerable dependencies.

Exam trap

KCSA often tests the confusion between runtime hardening controls (like disabling token automount) and build-time supply chain controls — candidates pick runtime options thinking they mitigate supply chain risk.

Full explanation →
203
MCQeasy

What is the primary security benefit of implementing Ingress TLS termination at the ingress controller rather than inside the application pods?

A.Automatically encrypting persistent volume storage
B.Centralized certificate management and reduced cryptographic overhead on application pods
C.Preventing the container runtime from executing untrusted binaries
D.Ensuring that all pod-to-pod communication is blocked
AnswerB

Terminating TLS at the ingress controller centralises certificate storage, rotation, and renewal in one place, and offloads cryptographic handshake work from application pods. This satisfies the goal of centralised certificate management with reduced per-pod cryptographic overhead.

Why this answer

Ingress TLS termination at the ingress controller centralizes TLS certificate management and offloads cryptographic operations from application pods. This means certificates are stored and rotated in one place (the ingress controller), and pods can handle plain HTTP, reducing their CPU overhead and simplifying certificate distribution. It also enables consistent TLS policies across multiple services.

Exam trap

KCSA often tests the misconception that Ingress TLS termination encrypts all traffic, including pod-to-pod or storage, when it only secures client-to-ingress traffic and offloads TLS from pods.

How to eliminate wrong answers

Option A is wrong because Ingress TLS termination does not encrypt persistent volume storage; that requires storage-level encryption (e.g., encrypted PVs or CSI drivers). Option C is wrong because preventing untrusted binary execution is a runtime security concern (e.g., seccomp, AppArmor), not related to TLS termination. Option D is wrong because Ingress TLS termination does not block pod-to-pod communication; network policies are needed for that, and TLS termination actually allows encrypted traffic from clients to the ingress, not blocking internal traffic.

Full explanation →
204
MCQeasy

Which NIST framework publication specifically addresses the security of container-based applications and orchestration systems?

A.NIST SP 800-190
B.NIST SP 800-37
C.NIST SP 800-53
D.NIST SP 800-88
AnswerA

NIST SP 800-190, "Application Container Security Guide", addresses container threats and countermeasures across image, registry, orchestrator, container and host layers. It is the publication dedicated to container-based applications and orchestration systems, satisfying the stem's specific framework requirement.

Why this answer

NIST SP 800-190, 'Application Container Security Guide', specifically addresses the security of container-based applications and orchestration systems. It provides guidance on container threats, vulnerabilities, and countermeasures, making it the correct publication for this topic.

Exam trap

KCSA often tests the specific NIST publication for container security; candidates may confuse it with broader frameworks like SP 800-53 or SP 800-37, which are not container-specific.

How to eliminate wrong answers

Option B is wrong because NIST SP 800-37 is the Risk Management Framework (RMF), which is a general security lifecycle framework, not specific to containers. Option C is wrong because NIST SP 800-53 is a catalog of security and privacy controls for federal information systems, not container-specific. Option D is wrong because NIST SP 800-88 provides guidelines for media sanitization, unrelated to containers.

Full explanation →
205
Multi-Selecthard

Which TWO of the following scenarios represent severe security misconfigurations in a Kubernetes cluster control plane? (Choose TWO)

Select 2 answers
A.Etcd is configured with client certificate authentication and mTLS enabled.
B.Kubelet authorization mode is set to Webhook.
C.The API server is configured with --insecure-port pointing to an active HTTP listener.
D.The API server or kubelet has anonymous authentication enabled (--anonymous-auth=true).
E.Secrets are encrypted at rest using an EncryptionConfiguration file.
AnswersC, D

Enabling the insecure port exposes the API server over unauthenticated, unencrypted HTTP, letting anyone reach it bypass the TLS and authentication controls that secure port 6443 enforces. This directly satisfies the stem's control-plane misconfiguration criterion, since anonymous requests could read or modify cluster state without credentials.

Why this answer

Option C is correct because configuring the API server with --insecure-port to an active HTTP listener exposes an unauthenticated, unencrypted endpoint that bypasses TLS and normal authentication/authorization, which is a severe control-plane misconfiguration. Option D is correct because enabling anonymous authentication (--anonymous-auth=true) on the API server or kubelet allows unauthenticated requests to be treated as the system:anonymous user, potentially granting access to sensitive endpoints or cluster resources. Option A is not a misconfiguration because client certificate authentication with mTLS is a recommended secure configuration for etcd.

Option B is not a misconfiguration because Webhook authorization mode is a valid and secure kubelet authorization setting. Option E is not a misconfiguration because encrypting Secrets at rest with an EncryptionConfiguration file is a security best practice.

Exam trap

The trap is misidentifying secure configurations (like mTLS, Webhook, encryption at rest) as misconfigurations, or not recognizing that anonymous auth and insecure port are dangerous.

Full explanation →
206
MCQhard

You are securing a highly regulated Kubernetes cluster and need to ensure that etcd data is encrypted at rest using a custom encryption key. After creating the EncryptionConfiguration file, which API server flag must be updated to point to this file?

A.--data-encryption-secret
B.--encryption-config-path
C.--encryption-provider-config
D.--etcd-key-file
AnswerC

The `--encryption-provider-config` flag on the kube-apiserver accepts the path to the EncryptionConfiguration file, enabling envelope encryption of etcd data at rest. Without it, the API server ignores your custom key configuration entirely, so secrets persist unencrypted on disk — failing the regulated cluster's at-rest encryption requirement.

Why this answer

The kube-apiserver flag --encryption-provider-config is the correct flag that points the API server to the EncryptionConfiguration YAML file defining the encryption providers (e.g., aescbc, kms) and their keys. Without this flag, the API server ignores the file entirely and etcd data remains unencrypted at rest. The flag was introduced with the EncryptionConfiguration API (stable since Kubernetes 1.13) and is required alongside the file itself for encryption to take effect.

Exam trap

KCSA often tests the exact spelling of the kube-apiserver encryption flag, luring candidates toward plausible-sounding but nonexistent names like --encryption-config-path or --data-encryption-secret.

How to eliminate wrong answers

Option A is wrong because --data-encryption-secret is not a real kube-apiserver flag; it conflates the concept of a secret key with a nonexistent CLI option. Option B is wrong because --encryption-config-path is a fabricated flag name; the actual flag uses 'provider' not 'path' in its name. Option D is wrong because --etcd-key-file is not a valid kube-apiserver flag — etcd TLS client key flags are named --etcd-certfile/--etcd-keyfile (no hyphen between key and file), and even those control TLS to etcd, not at-rest encryption of stored objects.

Full explanation →
207
Multi-Selectmedium

Under the cloud native shared responsibility model for a managed Kubernetes service, which TWO tasks are typically the responsibility of the cloud provider? (Choose TWO)

Select 2 answers
A.Writing custom application microservice source code
B.Configuring Kubernetes Role-Based Access Control (RBAC) rules
C.Provisioning and securing physical data center facilities and hardware
D.Managing and patching the managed Kubernetes control plane infrastructure
E.Applying Kubernetes NetworkPolicies between customer pods
AnswersC, D

Physical data centre facilities, power, cooling, hardware and perimeter security remain entirely under the cloud provider's control in every managed Kubernetes offering. Customers cannot access or secure these layers, so the provider owns them regardless of cluster configuration.

Why this answer

Option C is correct because in the shared responsibility model the cloud provider owns the physical layer — data center facilities, power, cooling, physical security, and the underlying hardware hosts — which customers cannot access or control in a managed Kubernetes service. Option D is correct because with a managed Kubernetes offering (e.g., EKS, AKS, GKE) the provider operates, patches, and maintains the control plane components such as the API server, etcd, scheduler, and controller manager, including their high availability and version upgrades. Option A is not the provider's responsibility because application source code is always authored and maintained by the customer.

Option B is not the provider's responsibility because RBAC rules governing who can access the cluster and its resources are configured by the customer. Option E is not the provider's responsibility because NetworkPolicies controlling pod-to-pod traffic within the customer's namespaces are defined and applied by the customer.

Exam trap

KCSA often tests the boundary between control plane and workload responsibilities — candidates incorrectly assume the provider manages RBAC or NetworkPolicies because those are 'Kubernetes' features, when they are actually customer-managed in a shared responsibility model.

Full explanation →
208
Multi-Selecteasy

When modeling threats for a Kubernetes cluster using the STRIDE methodology, identifying scenarios where an attacker intercepts unencrypted traffic between worker nodes or between a client and the API server addresses which TWO STRIDE categories? (Choose TWO)

Select 2 answers
A.Repudiation
B.Denial of Service
C.Tampering
D.Elevation of Privilege
E.Information Disclosure
AnswersC, E

Interception of unencrypted node-to-node or client-to-API-server traffic lets an attacker alter packets in transit, which is Tampering under STRIDE. The lack of transport encryption (no TLS) is the specific weakness enabling modification of data between endpoints.

Why this answer

Option C (Tampering) is correct because an attacker who intercepts unencrypted traffic between worker nodes or between a client and the API server can modify the data in transit, which directly violates integrity and matches STRIDE's Tampering category. Option E (Information Disclosure) is correct because intercepting unencrypted traffic exposes sensitive data such as credentials, tokens, or configuration details to unauthorized parties, which is exactly the confidentiality violation STRIDE classifies as Information Disclosure. Option A (Repudiation) does not apply because it concerns denying having performed an action and the lack of audit trails, not interception of traffic.

Option B (Denial of Service) does not apply because it concerns availability degradation or disruption, not passive interception or modification of communications. Option D (Elevation of Privilege) does not apply because it concerns gaining higher permissions than authorized, which is not the direct result of intercepting unencrypted traffic described here.

Exam trap

KCSA often tests the distinction between STRIDE categories by presenting scenarios that seem to fit multiple categories; candidates may overlook that interception enables both data exposure (Information Disclosure) and data modification (Tampering), or incorrectly attribute it to Repudiation or Elevation of Privilege.

Full explanation →
209
MCQmedium

An enterprise cluster requires that all incoming NetworkPolicies must default to denying all traffic unless explicitly allowed. A developer creates a namespace but forgets to apply any policies. What is the default behavior of Kubernetes regarding inter-pod traffic within a namespace when no NetworkPolicies are present?

A.Only traffic originating from the kube-system namespace is allowed.
B.All traffic between pods is allowed by default.
C.Traffic is allowed only if the pods share the same node.
D.All traffic between pods is denied by default.
AnswerB

Kubernetes NetworkPolicies are additive allowlists; with none applied to a namespace, no isolation exists and every pod-to-pod flow is permitted. The cluster's default-deny requirement therefore needs explicit policies, since the platform itself imposes no implicit denial.

Why this answer

Kubernetes NetworkPolicies operate on an additive allow-list model: if no policy selects a pod, that pod is non-isolated and all ingress/egress traffic is permitted. The default-deny posture only takes effect once at least one NetworkPolicy selects the pod and does not explicitly allow the traffic. Therefore, a namespace with zero policies allows unrestricted inter-pod communication.

Exam trap

KCSA often tests the misconception that Kubernetes ships with an implicit default-deny NetworkPolicy, when in reality pods are non-isolated and fully open until a policy explicitly selects them.

How to eliminate wrong answers

Option A is wrong because kube-system has no special traffic privileges over user namespaces — NetworkPolicies are namespace-scoped and there is no implicit allow rule for kube-system. Option C is wrong because pod-to-pod reachability is determined by the CNI overlay network, not by whether pods share a node; same-node and cross-node traffic are both allowed when no policy exists. Option D is wrong because Kubernetes does not implement an implicit default-deny; default-deny must be explicitly created by applying a policy that selects the pods and specifies empty ingress/egress rules.

Full explanation →
210
Multi-Selecthard

Which TWO of the following are valid ways to harden etcd against unauthorized access and data corruption? (Choose TWO)

Select 2 answers
A.Expose etcd directly over unencrypted HTTP on port 2379.
B.Disable client certificate verification to allow unrestricted access.
C.Require mutual TLS (mTLS) for all client and peer connections.
D.Take regular encrypted snapshots using etcdctl snapshot save.
E.Grant public anonymous write access to the etcd raft log.
AnswersC, D

Mutual TLS requires both client and peer connections to present valid certificates, so only authenticated etcd members and authorised clients can read or write data. This satisfies the hardening requirement by preventing unauthorised access and tampering with cluster state.

Why this answer

Option C is correct because requiring mutual TLS (mTLS) for all client and peer connections ensures that both ends of every etcd connection present valid certificates, so only authenticated clients and peers can read or write keys and participate in raft consensus, preventing unauthorized access. Option D is correct because taking regular encrypted snapshots with etcdctl snapshot save (typically combined with encryption at rest or encrypting the snapshot file) preserves a recoverable copy of the datastore, allowing restoration after data corruption or compromise. Option A is wrong because exposing etcd over unencrypted HTTP on port 2379 sends credentials and data in cleartext and is exactly the insecure default that hardening must avoid.

Option B is wrong because disabling client certificate verification removes authentication entirely, allowing unrestricted access. Option E is wrong because granting public anonymous write access to the raft log lets anyone corrupt cluster state and violates the principle of least privilege.

Exam trap

KCSA often tests whether candidates recognize insecure etcd configurations; the trap is choosing options that sound like convenience features but actually weaken security, such as disabling certificate verification.

Full explanation →
211
MCQmedium

An external penetration tester managed to achieve remote code execution inside a container. They attempt to query the Kubernetes API server using the service account token mounted inside the container. To minimize the blast radius of such an attack, which setting should be explicitly configured on the Pod spec?

A.shareProcessNamespace: false
B.automountServiceAccountToken: false
C.hostIPC: false
D.hostNetwork: false
AnswerB

Setting automountServiceAccountToken to false stops the projected service account token being mounted into the pod's filesystem. Without that credential, code execution inside the container cannot authenticate to the Kubernetes API server, shrinking the blast radius.

Why this answer

By default, Kubernetes mounts a service account token into every pod at /var/run/secrets/kubernetes.io/serviceaccount/token, which an attacker with RCE can read and use to authenticate to the API server. Setting automountServiceAccountToken: false on the Pod spec prevents that token from being mounted, removing the credential the attacker needs to pivot to the API server. This directly shrinks the blast radius of a container compromise.

Exam trap

KCSA often tests whether candidates know that automountServiceAccountToken is the specific control for removing API credentials from pods, while hostNetwork, hostIPC, and shareProcessNamespace are namespace-isolation controls that do not address token exposure.

How to eliminate wrong answers

Option A is wrong because shareProcessNamespace controls whether containers in a pod share a PID namespace; it has no bearing on API server credentials. Option C is wrong because hostIPC only affects whether the pod shares the host's IPC namespace — it does not remove the mounted service account token. Option D is wrong because hostNetwork controls whether the pod uses the host network stack; while it is a security-relevant setting, it does not prevent the service account token from being mounted and abused.

Full explanation →
212
Multi-Selecteasy

Which TWO of the following are primary components of the 4Cs of Cloud Native Security model? (Choose TWO)

Select 2 answers
A.Container
B.Client
C.Crypto
D.Code
E.Compliance
AnswersA, D

Container is the innermost of the four cumulative layers — Cloud, Cluster, Container, Code — so it is a primary component. Hardening the container layer covers image provenance, runtime isolation and least-privilege SecurityContexts, satisfying the stem's requirement for a named 4Cs component.

Why this answer

The 4Cs of Cloud Native Security model defines four layers of defense: Cloud, Cluster, Container, and Code, so option A (Container) is correct because the container layer covers securing the container image, its runtime, and its contents. Option D (Code) is also correct because the code layer is the innermost layer, focusing on securing application source code, dependencies, and CI/CD pipelines. The remaining options do not belong: Client (B) is not one of the 4Cs, Crypto (C) is a security mechanism rather than a layer in this model, and Compliance (E) is a governance concern, not a named component of the 4Cs.

Exam trap

KCSA often tests candidates who confuse the 4Cs with generic security domains like compliance or cryptography, rather than the specific Cloud, Cluster, Container, Code layers.

Full explanation →
213
MCQmedium

You are troubleshooting a container image vulnerability scan report that flagged a high-severity CVE in a base image layer. The development team wants to ensure that vulnerable container images are automatically prevented from being deployed to any namespace in the cluster. Which Kubernetes mechanism should you implement?

A.Enable resource quotas on the default namespace
B.Rotate the cluster certificate authority
C.Add network policies to restrict outbound CVE database queries
D.Configure a validating admission webhook to inspect image metadata and reject deployments with known CVEs
AnswerD

A validating admission webhook intercepts pod creation requests, queries image metadata against vulnerability data, and rejects any workload whose image contains known CVEs. This enforces prevention cluster-wide at admission time, satisfying the requirement to block deployment automatically.

Why this answer

A validating admission webhook intercepts pod creation requests before they are persisted to etcd and can inspect image metadata (via registries or scanning tools) to reject deployments containing known CVEs. This enforces policy at the cluster level across all namespaces, preventing vulnerable images from ever running.

Exam trap

KCSA often tests whether candidates confuse admission control (pre-deployment enforcement) with runtime controls like NetworkPolicies or quotas — only admission webhooks can block deployments based on image content.

How to eliminate wrong answers

Option A is wrong because resource quotas limit CPU/memory/object counts, not image vulnerability status, and they do not block deployments based on CVE content. Option B is wrong because rotating the cluster certificate authority is a PKI hygiene task unrelated to image vulnerability enforcement. Option C is wrong because network policies control pod-to-pod traffic and cannot inspect image metadata or block deployments; restricting outbound CVE database queries would actually break scanning, not enforce it.

Full explanation →
214
MCQmedium

Under NIST guidelines for continuous monitoring in cloud-native environments, which Kubernetes mechanism allows operators to enforce cryptographic integrity of container images at runtime?

A.Image signing and verification via admission controllers
B.Increasing pod memory limits
C.Disabling the default namespace
D.Using ClusterRoleBindings with wildcards
AnswerA

Admission controllers intercept pod creation and verify cryptographic signatures against trusted keys before permitting the image to run. This enforces integrity at runtime admission, satisfying NIST continuous monitoring by blocking unsigned or tampered images from executing in the cluster.

Why this answer

Admission controllers in Kubernetes can intercept pod creation requests and validate that container images are signed by trusted authorities before allowing them to run. By integrating image signing (e.g., Cosign/Notary) with an admission controller (e.g., OPA Gatekeeper, Kyverno, or the Sigstore policy controller), operators enforce cryptographic integrity at runtime admission. This directly satisfies NIST continuous monitoring guidance for verifying artifact integrity in cloud-native environments.

Exam trap

The trap is confusing resource or RBAC settings (memory limits, namespace changes, wildcard bindings) with actual integrity enforcement mechanisms — only admission control combined with image signing provides cryptographic verification.

How to eliminate wrong answers

Option B is wrong because increasing pod memory limits is a resource tuning action with no security or integrity enforcement capability. Option C is wrong because disabling the default namespace is a weak hygiene measure that does not verify image integrity and can break workloads relying on that namespace. Option D is wrong because ClusterRoleBindings with wildcards grant excessive permissions, expanding the attack surface rather than enforcing cryptographic image integrity — it is an anti-pattern, not a control.

Full explanation →
215
Multi-Selecthard

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

Select 3 answers
A.Granting cluster-admin permissions to all application service accounts
B.Implementing microsegmentation via Kubernetes NetworkPolicies and service mesh auth policies
C.Enforcing mutual TLS (mTLS) for all internal service-to-service communications
D.Applying strict admission webhook policies to validate workloads before creation
E.Assuming internal cluster networks are fully secure and trusting all pods by default
AnswersB, C, D

Microsegmentation enforces least-privilege east-west traffic between workloads, satisfying zero trust's assumption of no implicit internal trust. Kubernetes NetworkPolicies filter pod-level IP and port flows, while service mesh authorisation policies add identity-based mTLS verification at layer seven, together restricting lateral movement within the cluster.

Why this answer

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.

Exam trap

KCSA often tests whether candidates conflate zero-trust with 'trust everything inside the cluster' — the exam expects you to reject any option that assumes implicit trust based on network location.

Full explanation →
216
MCQhard

An administrator wishes to defend against supply chain attacks involving malicious third-party Kubernetes operators installed from public catalogs. What security practice is most effective before installing such operators?

A.Reviewing requested RBAC permissions, operator manifests, and verifying image provenance
B.Enabling Horizontal Pod Autoscaling for CoreDNS replicas
C.Disabling the Kubernetes Dashboard service deployment
D.Configuring liveness probes on all worker nodes to check kubelet responsiveness
AnswerA

Inspecting the operator's requested RBAC permissions, its manifests, and verifying image provenance and signatures exposes over-privileged requests or tampered images before installation, directly mitigating malicious third-party operators from public catalogs. This pre-installation review addresses the supply chain risk at its source.

Why this answer

Before installing third-party operators, the most effective practice is to review the requested RBAC permissions, inspect the operator manifests for suspicious resources, and verify image provenance (e.g., signatures, trusted registries). This due diligence helps detect malicious intent, such as excessive privileges or backdoors, before the operator is deployed.

Exam trap

KCSA often tests the confusion between operational best practices (like HPA or liveness probes) and security practices (like RBAC review and image provenance) for supply chain defense.

How to eliminate wrong answers

Option B is wrong because enabling Horizontal Pod Autoscaling for CoreDNS is unrelated to supply chain security and does not mitigate malicious operators. Option C is wrong because disabling the Kubernetes Dashboard, while a good hardening step, does not address the risk of third-party operators. Option D is wrong because configuring liveness probes on worker nodes is an operational health check, not a security control against supply chain attacks.

Full explanation →
217
Multi-Selecteasy

Which TWO of the following actions are risks associated with leaving the Kubernetes API server's insecure port enabled? (Choose TWO)

Select 2 answers
A.Enforcement of strict TLS 1.3 encryption on all connections.
B.Complete bypass of all authentication mechanisms.
C.Mandatory mutual TLS client certificate verification.
D.Automatic activation of etcd encryption at rest.
E.Complete bypass of all authorization checks (RBAC).
AnswersB, E

The insecure port serves requests over plain HTTP with no authentication or authorisation checks applied, so any client reaching it acts as an anonymous, fully privileged user. This directly satisfies the stem's constraint: it grants complete bypass of all authentication mechanisms, exposing the cluster to unauthenticated API operations.

Why this answer

The insecure port (historically --insecure-port, default 8080) on the Kubernetes API server serves requests over plain HTTP with no TLS, and by design it does not perform any authentication, so option B is correct: any client that can reach that port is treated as an anonymous, unauthenticated user. Because requests arriving on the insecure port are also not subjected to authorization checks, option E is correct: the usual RBAC evaluation is skipped, effectively granting the caller full access to the API as if they were an administrator. Options A and C are wrong because TLS 1.3 enforcement and mutual TLS client certificate verification are properties of the secure port (6443), not the insecure one, which uses no encryption or client certs at all.

Option D is wrong because etcd encryption at rest is configured separately via EncryptionConfiguration on the kube-apiserver and is never automatically activated by the insecure port.

Exam trap

The trap is picking TLS-related options (A or C) because the word 'insecure' suggests weak encryption; in reality the insecure port has no TLS and no authN/authZ, so the correct risks are complete bypass of both.

Full explanation →
218
MCQmedium

A cluster operator is enforcing the Pod Security Standards "restricted" profile across a namespace. A developer attempts to deploy a container running as root (runAsUser: 0). What will happen during the admission phase?

A.The pod will be created, but the kubelet will override the user ID to 65534 at runtime.
B.The pod will start successfully in audit mode, generating a warning event in the API server logs.
C.The PodSecurity admission controller will reject the pod creation request.
D.The container will drop all Linux capabilities and proceed with deployment.
AnswerC

Under the restricted profile, runAsNonRoot is mandatory, so a container specifying runAsUser: 0 violates the policy. The PodSecurity admission controller evaluates this during admission and denies the request, preventing the pod from being created in the namespace.

Why this answer

The restricted Pod Security Standard requires containers to run as non-root, among other hardening measures. When a pod attempts to run as root (runAsUser: 0) in a namespace enforcing the restricted profile, the PodSecurity admission controller will reject the pod creation request during the admission phase. This prevents the pod from being created at all.

Exam trap

The trap is confusing audit mode with enforce mode, or thinking that the kubelet or runtime will fix the violation, when in fact the admission controller rejects the pod outright.

How to eliminate wrong answers

Option A is wrong because the kubelet does not override the user ID; the admission controller blocks the pod before it reaches the kubelet. Option B is wrong because audit mode only logs violations and does not block; but the question states 'enforcing', so it's enforce mode, not audit. Option D is wrong because dropping capabilities does not automatically happen; the restricted profile requires capabilities to be dropped, but if the pod doesn't comply, it is rejected, not modified.

Full explanation →
219
Multi-Selectmedium

Which TWO components are involved when an Ingress controller routes external HTTPS traffic to a backend service in Kubernetes? (Choose two)

Select 2 answers
A.The kube-apiserver etcd storage backend encryption key
B.The coreDNS server managing TLS private keys
C.The persistent volume CSI controller
D.The Ingress resource object defining routing rules and TLS hosts
E.The Ingress Controller pod implementing the reverse proxy logic
AnswersD, E

The Ingress resource holds the routing rules and TLS host definitions that the controller reads and translates into proxy configuration. Without this object, the controller has no host or path mapping to program, so it is a required component in the traffic path.

Why this answer

Option D is correct because the Ingress resource is the declarative API object that defines the routing rules (host/path to backend Service mappings) and the TLS configuration, including the tls.hosts and secretName fields that specify which certificate to use for HTTPS termination. Option E is correct because the Ingress Controller pod (e.g., NGINX Ingress Controller, Traefik, HAProxy) is the actual data-plane component that watches Ingress resources and implements the reverse proxy logic, terminating TLS and forwarding requests to the backend Service's endpoints. Option A is incorrect because the kube-apiserver's etcd encryption key protects data at rest in etcd and plays no role in routing external HTTPS traffic.

Option B is incorrect because CoreDNS provides cluster DNS resolution for service names, not TLS private key management. Option C is incorrect because the CSI controller handles persistent volume provisioning and attachment, which is unrelated to Ingress traffic routing.

Exam trap

The trap here is that candidates pick CoreDNS or etcd because they are 'Kubernetes components' — the exam tests whether you know that Ingress routing involves only the Ingress resource and the Ingress Controller, not the control-plane data stores.

Full explanation →
220
MCQhard

An organization requires compliance auditing of etcd access to ensure unauthorized clients cannot communicate with the data store. According to CIS benchmarks, how should etcd client communication be secured?

A.IPsec tunnel encapsulation
B.Mutual TLS (mTLS) client certificates
C.HTTP with token bearer headers
D.Plaintext loopback interface binding
AnswerB

Mutual TLS forces both etcd server and client to present certificates signed by a trusted CA, so unauthenticated clients are rejected during the handshake. This directly satisfies the CIS benchmark requirement for encrypted, authenticated etcd client communication, preventing unauthorised access to the data store.

Why this answer

CIS Kubernetes Benchmark requires that etcd client communication be encrypted and mutually authenticated. Mutual TLS (mTLS) ensures both the client and the etcd server present certificates signed by a trusted CA, preventing unauthorized clients from connecting. This is enforced via flags like --cert-file, --key-file, --client-cert-auth, and --trusted-ca-file on the etcd server.

Exam trap

KCSA often tests the misconception that network-level controls like IPsec or loopback binding satisfy CIS etcd requirements, when the benchmark specifically mandates mutual TLS client certificate authentication.

How to eliminate wrong answers

Option A is wrong because IPsec tunnel encapsulation is a network-layer VPN technique, not the CIS-prescribed method for etcd client authentication and is not how etcd verifies client identity. Option C is wrong because HTTP with token bearer headers provides no transport encryption and etcd does not use bearer tokens for client authentication. Option D is wrong because plaintext loopback binding only restricts etcd to localhost without encryption or authentication, and it does not satisfy CIS requirements for client communication security.

Full explanation →
221
MCQeasy

What is the primary function of the 'automountServiceAccountToken: false' setting in a Pod specification?

A.It deletes the ServiceAccount object from the cluster when the pod terminates.
B.It prevents the pod from communicating with the Kubernetes API server entirely.
C.It disables RBAC authorization checks for the pod.
D.It prevents the ServiceAccount API token from being automatically mounted inside the pod.
AnswerD

Setting `automountServiceAccountToken: false` stops the kubelet projecting the ServiceAccount token into the pod's filesystem at `/var/run/secrets/kubernetes.io/serviceaccount`. This satisfies the least-privilege constraint: workloads that never call the Kubernetes API avoid holding a credential that could be stolen and replayed against the API server.

Why this answer

The 'automountServiceAccountToken: false' setting in a Pod specification prevents the default ServiceAccount token from being automatically mounted into the pod's filesystem. This reduces the attack surface by ensuring the pod does not have credentials to access the Kubernetes API unless explicitly mounted. It does not delete the ServiceAccount, disable RBAC, or block all API communication.

Exam trap

KCSA often tests the misunderstanding that automountServiceAccountToken: false blocks all API access or deletes the ServiceAccount, when it only prevents automatic token mounting.

How to eliminate wrong answers

Option A is wrong because the setting does not delete the ServiceAccount object; it only affects token mounting. Option B is wrong because it does not prevent the pod from communicating with the API server entirely; the pod can still communicate if it obtains a token through other means or if the application doesn't need a token. Option C is wrong because it does not disable RBAC authorization checks; RBAC is enforced by the API server regardless of token mounting.

Full explanation →
222
Multi-Selecteasy

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

Select 2 answers
A./etc/kubernetes/manifests/etcd.yaml
B./var/lib/kubelet/config.yaml
C./etc/default/kube-proxy
D.~/.kube/config
E./etc/kubernetes/manifests/kube-apiserver.yaml
AnswersA, E

Static pod manifests for control plane components live in /etc/kubernetes/manifests, and etcd.yaml defines the etcd static pod. This file contains the arguments and configuration for the cluster datastore, making it a critical manifest on control plane nodes.

Why this answer

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.

Exam trap

KCSA often tests the confusion between kubelet configuration files (like /var/lib/kubelet/config.yaml) and the static pod manifest directory (/etc/kubernetes/manifests), or between client-side kubeconfig (~/.kube/config) and server-side static pod definitions.

Full explanation →
223
Multi-Selectmedium

Which TWO of the following metrics or health endpoints should be protected against unauthenticated access on control plane nodes? (Choose TWO)

Select 2 answers
A.Container runtime image download caches.
B.Etcd metrics and health endpoints (typically port 2379/2380).
C.Public load balancer health check probe targets configured for external routing.
D.CoreDNS internal DNS query forwarding ports.
E.Kubelet metrics and operational endpoints (port 10250).
AnswersB, E

Etcd's 2379 client and 2380 peer ports expose the full keyspace, including Secrets, and permit writes. Protecting them satisfies the stem's constraint because unauthenticated access to these metrics and health endpoints on control plane nodes yields direct cluster takeover, far exceeding mere information disclosure.

Why this answer

Option B is correct because etcd exposes sensitive metrics and health endpoints on ports 2379 (client) and 2380 (peer), and unauthenticated access to these can leak cluster state, keys, and allow disruptive operations, so they must be protected on control plane nodes. Option E is correct because the kubelet serves metrics and operational endpoints on port 10250, and unauthenticated access there can expose pod specs, logs, and even permit command execution via the kubelet API, making authentication and authorization essential. Option A is not a control plane health or metrics endpoint; container image caches are local storage artifacts, not network services requiring this protection.

Option C refers to external load balancer probe targets, which are typically intentionally reachable and are not control plane node metrics/health endpoints. Option D concerns CoreDNS internal DNS forwarding ports, which are part of cluster DNS service traffic rather than control plane node metrics or health endpoints.

Exam trap

KCSA often tests the specific ports and endpoints that are sensitive, and candidates may overlook kubelet (10250) or etcd (2379/2380) in favor of less critical components.

Full explanation →
224
MCQmedium

An administrator needs to configure an Ingress resource to route traffic securely to a backend service using HTTPS (TLS between the ingress controller and the backend pod). Which NGINX Ingress annotation enables this backend HTTPS communication?

A.nginx.ingress.kubernetes.io/ssl-redirect: "true"
B.nginx.ingress.kubernetes.io/proxy-connect-timeout
C.nginx.ingress.kubernetes.io/backend-protocol: "HTTPS"
D.nginx.ingress.kubernetes.io/cors-allow-origin
AnswerC

The `nginx.ingress.kubernetes.io/backend-protocol: "HTTPS"` annotation instructs the NGINX ingress controller to establish TLS when connecting to the backend pod, satisfying the stem's requirement for HTTPS between controller and service. Without it, NGINX defaults to plain HTTP to the backend, so traffic would be unencrypted regardless of the client-facing TLS configuration.

Why this answer

The annotation nginx.ingress.kubernetes.io/backend-protocol: "HTTPS" tells the NGINX Ingress Controller to speak HTTPS when connecting to the backend service, enabling TLS between the controller and the pod. This is the standard way to terminate TLS at the ingress and re-encrypt to the backend, satisfying end-to-end encryption requirements. Without this annotation, NGINX defaults to HTTP for backend connections even if the Service port is named 'https'.

Exam trap

KCSA often tests whether candidates confuse client-side TLS enforcement (ssl-redirect) with backend transport encryption (backend-protocol), causing them to pick the redirect annotation when the question asks about ingress-to-pod TLS.

How to eliminate wrong answers

Option A is wrong because ssl-redirect only forces HTTP clients to redirect to HTTPS at the ingress listener; it does not affect the protocol used between the ingress controller and the backend pod. Option B is wrong because proxy-connect-timeout only controls how long NGINX waits for a TCP connection to the upstream — it has no bearing on whether TLS is used. Option D is wrong because cors-allow-origin configures Cross-Origin Resource Sharing response headers for browser clients, which is unrelated to backend transport security.

Full explanation →
225
MCQhard

An administrator needs to restrict a container from accessing any devices on the host system via device nodes. By default, how does Docker or containerd handle device access for containers when no custom security profile is applied?

A.By disabling all system calls related to file I/O
B.By routing all device access requests through kube-proxy
C.By applying a default device allowlist that restricts access to essential devices like /dev/null and /dev/random
D.By mounting the entire host /dev directory in read-write mode
AnswerC

Docker and containerd apply a default device cgroup allowlist permitting only essential nodes such as /dev/null, /dev/zero, /dev/random and tty devices. Without a custom profile, all other host device nodes remain inaccessible, satisfying the restriction requirement.

Why this answer

By default, Docker and containerd apply a default device allowlist that permits access only to essential devices like /dev/null, /dev/zero, /dev/random, and /dev/urandom, while denying access to all other host devices. This is implemented via the default cgroup device controller policy.

Exam trap

KCSA often tests the misconception that containers have unrestricted device access by default — candidates may think the host /dev is mounted, but the default allowlist is a key security control.

How to eliminate wrong answers

Option A is wrong because disabling all file I/O syscalls would break the container entirely and is not how device access is restricted. Option B is wrong because kube-proxy handles network routing, not device access. Option D is wrong because mounting the entire host /dev read-write would be a severe security risk and is not the default behavior.

Full explanation →
Page 2

Page 3 of 4

Page 4

All pages

1234

Practice KCSA by domain

Target a specific domain to shore up weak areas.

Kubernetes Security FundamentalsOverview OF Cloud Native SecurityCompliance And Security FrameworksKubernetes Cluster Component SecurityKubernetes Threat ModelPlatform Security
See all domains with question counts →