Courseiva

Kubernetes and Cloud Native Security Associate (KCSA, CNCF) (KCSA) (KCSA) — Questions 76–150

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

Take a mock examExam hub
Page 1

Page 2 of 4

Page 3
76
MCQeasy

When considering the principle of least privilege within a cloud native architecture, what is the recommended approach for granting permissions to a Kubernetes application running in a Pod?

A.Share a single global ServiceAccount across all namespaces in the cluster.
B.Mount the default ServiceAccount token with cluster-admin rights to ensure compatibility.
C.Disable authentication for the application namespace entirely.
D.Create a dedicated ServiceAccount with strictly scoped RBAC roles granting only required API permissions.
AnswerD

A dedicated ServiceAccount bound to narrowly scoped RBAC roles grants the Pod only the specific API verbs and resources it needs, rather than inheriting broad default permissions. This enforces least privilege at the Kubernetes API authorisation layer.

Why this answer

Least privilege in Kubernetes is achieved by creating a dedicated ServiceAccount per workload and binding it to narrowly scoped Roles or ClusterRoles that grant only the specific API verbs and resources the application needs. This limits the blast radius if the Pod is compromised, since its mounted token can only perform the permitted actions.

Exam trap

KCSA often tests least privilege by offering 'convenience' answers like cluster-admin or a shared ServiceAccount, so candidates optimizing for compatibility rather than security pick the over-privileged option.

How to eliminate wrong answers

Option A is wrong because a single global ServiceAccount shared across namespaces violates least privilege—any compromise grants the same permissions cluster-wide and eliminates per-workload isolation. Option B is wrong because mounting the default ServiceAccount token with cluster-admin rights grants full control of the cluster, the exact opposite of least privilege, and the default token is auto-mounted unless disabled. Option C is wrong because disabling authentication removes the ability to authorize or audit requests, effectively granting anonymous access rather than restricting it.

Full explanation →
77
MCQeasy

What is the primary purpose of vulnerability scanning databases (such as Trivy, Grype, or Clair) when integrated into a container platform?

A.To match package versions inside container images against known CVE databases and report vulnerabilities
B.To enforce network microsegmentation rules
C.To balance incoming web traffic across backend replicas
D.To automatically rotate cluster TLS certificates
AnswerA

Scanners extract installed package versions from image layers and compare them against CVE feeds, reporting matches. This satisfies the stem by identifying known vulnerabilities in image contents before deployment, rather than blocking runtime behaviour or enforcing policy.

Why this answer

Vulnerability scanning databases like Trivy, Grype, and Clair work by extracting the installed package inventory (OS packages, language libraries) from a container image and matching those versions against known CVE feeds such as NVD, GHSA, and vendor advisories. They report CVEs with severity, fixed versions, and package paths so teams can remediate before deployment. This is the core function of an image scanner — it is not a runtime enforcement or networking tool.

Exam trap

KCSA often tests whether candidates confuse image scanning (build-time CVE detection) with runtime security controls like seccomp, AppArmor, or network policies — the scanner finds vulnerabilities, it does not prevent exploitation.

How to eliminate wrong answers

Option B is wrong because network microsegmentation is enforced by CNI plugins and Kubernetes NetworkPolicies, not by image scanners. Option C is wrong because traffic balancing across backend replicas is the job of a Service, Ingress controller, or load balancer, not a CVE database. Option D is wrong because TLS certificate rotation is handled by cert-manager, kubelet certificate rotation, or the cloud provider's control plane — vulnerability scanners do not manage certificates.

Full explanation →
78
MCQhard

An enterprise security policy states that all infrastructure must be defined as code (IaC) and scanned for security misconfigurations before deployment. Which part of the cloud native security lifecycle does this control target?

A.Kernel patch management
B.Physical data center security
C.Pre-deployment configuration and policy-as-code validation
D.Runtime security monitoring
AnswerC

Scanning IaC templates for misconfigurations happens before any resource is provisioned, so it maps to pre-deployment configuration and policy-as-code validation. Failures block the pipeline rather than surfacing at runtime, which is precisely what the stated policy demands.

Why this answer

The policy requires infrastructure to be defined as code and scanned for misconfigurations before deployment, which directly targets the pre-deployment phase of the cloud native security lifecycle. This is where configuration and policy-as-code validation occur, ensuring that security issues are caught early in the CI/CD pipeline. Tools like Checkov, tfsec, or OPA/Gatekeeper enforce these checks.

Thus, option C correctly identifies this control.

Exam trap

The trap here is confusing pre-deployment IaC scanning with runtime security monitoring, as both involve security checks but at different lifecycle stages.

How to eliminate wrong answers

Option A is wrong because kernel patch management focuses on maintaining the host OS kernel, not on defining or scanning infrastructure as code. Option B is wrong because physical data center security involves protecting the physical environment, which is unrelated to IaC scanning. Option D is wrong because runtime security monitoring detects threats during execution, whereas the policy targets pre-deployment validation.

Full explanation →
79
MCQeasy

An administrator needs to enforce mTLS (Mutual TLS) across all microservices within a service mesh without modifying application code. Which component is automatically injected into each application pod to handle the encryption and decryption of traffic?

A.Container runtime shim
B.Kube-proxy
C.Ingress controller
D.Sidecar proxy
AnswerD

The sidecar proxy is injected alongside each application container and transparently intercepts inbound and outbound traffic, performing mTLS handshakes and encryption. Applications need no code changes, satisfying the stem's constraint of enforcing mutual TLS across all microservices automatically.

Why this answer

A sidecar proxy is a secondary container deployed alongside the application container within the same pod. In service meshes like Istio or Linkerd, the sidecar proxy (e.g., Envoy) intercepts all inbound and outbound traffic, handles mTLS handshakes, certificate rotation, and encryption/decryption transparently — no application code changes are needed. This is the core mechanism for zero-trust networking in Kubernetes service meshes.

Exam trap

KCSA often tests the confusion between north-south traffic components (ingress controllers) and east-west traffic components (sidecar proxies), leading candidates to pick the ingress controller for internal service-to-service encryption.

How to eliminate wrong answers

Option A is wrong because the container runtime shim (e.g., containerd-shim) manages container lifecycle and low-level runtime operations, not application-layer traffic encryption. Option B is wrong because kube-proxy implements Kubernetes Service abstraction (iptables/IPVS rules) for load balancing, but it does not perform mTLS or application-layer encryption. Option C is wrong because an ingress controller handles north-south traffic entering the cluster (HTTP/HTTPS routing), not east-west mTLS between microservices.

Full explanation →
80
Multi-Selecthard

Which THREE of the following steps are recognized best practices for hardening worker nodes against attacks and container escapes?

Select 3 answers
A.Keeping node host operating system kernels and container runtimes regularly patched
B.Configuring all pods to execute with `securityContext.runAsUser: 0`
C.Disabling the Kubelet read-only port (10255)
D.Allowing anonymous authentication requests on the Kubelet API
E.Restricting direct SSH access to worker nodes and using secure bastion hosts
AnswersA, C, E

Regular patching of host kernels and container runtimes directly closes the privilege-escalation vulnerabilities that container escapes exploit, satisfying the stem's hardening requirement. Because containers share the node kernel, an unpatched runtime or kernel flaw lets an attacker break isolation and reach the host, so timely updates are a recognised best practice.

Why this answer

Option A is correct because regularly patching node host OS kernels and container runtimes closes known privilege-escalation and container-escape vulnerabilities (e.g., runc CVEs) that attackers exploit to break out of containers. Option C is correct because the Kubelet read-only port 10255 serves unauthenticated pod and node metadata; disabling it (or ensuring it is not enabled, since it is deprecated/removed in newer Kubernetes) prevents unauthenticated information disclosure and reconnaissance. Option E is correct because restricting direct SSH access to worker nodes and requiring hardened bastion hosts reduces the attack surface and enforces auditable, controlled administrative access to nodes.

Option B is wrong because running pods as UID 0 (root) violates least privilege and increases the impact of a container escape. Option D is wrong because allowing anonymous authentication on the Kubelet API exposes node and pod operations to unauthenticated users and should be disabled via --anonymous-auth=false.

Exam trap

KCSA often tests whether candidates confuse 'running as root' with administrative necessity — the trap is picking `runAsUser: 0` as a hardening step when it is actually a critical misconfiguration, and forgetting that the read-only Kubelet port 10255 is unauthenticated by design.

Full explanation →
81
MCQmedium

An administrator needs to ensure that the Kubernetes API server does not allow insecure cipher suites during TLS handshakes. Which API server flag allows specifying the exact cipher suites permitted?

A.--cipher-list
B.--tls-cipher-suites
C.--secure-ciphers
D.--etcd-cipher-suites
AnswerB

The --tls-cipher-suites flag accepts an explicit comma-separated list of permitted cipher suites, restricting TLS handshakes to approved algorithms. It directly satisfies the requirement to disallow insecure suites by overriding the API server's default cipher selection.

Why this answer

The --tls-cipher-suites flag on the kube-apiserver allows administrators to specify a comma-separated list of allowed cipher suites for TLS handshakes. This directly controls which cipher suites the API server will accept, enabling compliance with security policies that require strong ciphers and disallow insecure ones.

Exam trap

The trap is that candidates may confuse --etcd-cipher-suites with --tls-cipher-suites; the former is for etcd communication, while the latter is for the API server's own TLS endpoint.

How to eliminate wrong answers

Option A is wrong because --cipher-list is not a valid kube-apiserver flag; it does not exist. Option C is wrong because --secure-ciphers is not a valid kube-apiserver flag. Option D is wrong because --etcd-cipher-suites is used to configure cipher suites for the connection between the API server and etcd, not for the API server's own TLS handshakes with clients.

Full explanation →
82
MCQeasy

An organization wants to analyze potential threats to their Kubernetes cluster using the STRIDE model. Which STRIDE category maps to an attacker eavesdropping on unencrypted internal cluster traffic between pods?

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

Information Disclosure covers data exposure to unauthorised parties, matching the eavesdropping scenario precisely. Unencrypted pod-to-pod traffic lets an attacker on the network read payloads in transit, violating confidentiality. STRIDE assigns confidentiality breaches to Information Disclosure, so it satisfies the stem's requirement of mapping the eavesdropping threat correctly.

Why this answer

Information Disclosure in the STRIDE model covers threats where data is exposed to unauthorized parties, such as eavesdropping on unencrypted traffic. An attacker sniffing internal cluster traffic between pods to read sensitive data is a classic Information Disclosure threat. The other STRIDE categories address different threat types, such as tampering with data or denying service.

Exam trap

KCSA often tests STRIDE categories, and candidates may confuse Information Disclosure with Tampering or Repudiation; the key is that eavesdropping is a confidentiality breach, which maps to Information Disclosure.

How to eliminate wrong answers

Option A is wrong because Repudiation involves denying having performed an action, such as an attacker covering their tracks, not eavesdropping. Option B is wrong because Tampering involves unauthorized modification of data or systems, not passive interception. Option D is wrong because Denial of Service involves making a service unavailable, not reading traffic.

Full explanation →
83
MCQhard

You are auditing the Kubernetes control plane and notice that the API server is configured with an insecure port (--insecure-port=8080). What is the primary security implication of leaving this port enabled?

A.It bypasses all authentication and authorization modules, granting full administrative access to anyone who reaches the port.
B.It prevents the kubelet from communicating with the control plane nodes.
C.It restricts API access exclusively to read-only operations.
D.It forces all clients to downgrade their TLS encryption cipher suites to plaintext.
AnswerA

The insecure port serves requests without passing them through authentication or authorization, so any client reaching port 8080 obtains full administrative API access. Disabling it removes this unauthenticated bypass of the control plane's access controls.

Why this answer

The --insecure-port flag on the kube-apiserver opens an unauthenticated, unencrypted HTTP endpoint that completely bypasses the normal authentication (x509 client certs, bearer tokens, OIDC) and authorization (RBAC, ABAC, Node authorizer) chain. Any client that can reach that port — including a compromised pod on the host network or a misconfigured firewall — is treated as an anonymous, fully privileged user and can perform any API action, including creating cluster-admin bindings. This is why the flag was deprecated in Kubernetes 1.20 and removed in 1.24.

Exam trap

KCSA often tests the misconception that the insecure port is merely 'unencrypted but still authenticated' — candidates pick options about TLS downgrade or read-only access, missing that the flag's real danger is total bypass of both authentication and authorization.

How to eliminate wrong answers

Option B is wrong because kubelet-to-apiserver communication uses the secure port (default 6443) with client certificates issued by the cluster CA; the insecure port has no bearing on kubelet connectivity. Option C is wrong because the insecure port does not restrict verbs — it grants the full API surface, including write and delete operations, to anonymous callers. Option D is wrong because the insecure port does not negotiate TLS at all; it serves plain HTTP, so there are no cipher suites to downgrade, and it does not affect the TLS configuration of the secure port.

Full explanation →
84
MCQhard

You are hardening a production Kubernetes control plane. You need to ensure that etcd client-to-server and peer communications are strictly encrypted in transit and require mutual TLS (mTLS). Which etcd configuration flag combination enforces this requirement?

A.--auto-tls=true for all endpoints.
B.--client-cert-auth=true and --peer-client-cert-auth=true along with valid CA and key pair paths.
C.--insecure-transport=false combined with HTTP proxy routing.
D.--cipher-suites=TLS_RSA_WITH_AES_128_CBC_SHA
AnswerB

Setting `--client-cert-auth=true` and `--peer-client-cert-auth=true` forces etcd to verify client and peer certificates against the configured CA, delivering the mutual TLS the stem demands. Supplying the CA and key pair paths enables that verification for both client-to-server and peer traffic, so all control plane communication is encrypted and mutually authenticated.

Why this answer

The flags --client-cert-auth=true and --peer-client-cert-auth=true force etcd to require and verify client certificates on both the client-facing listener (port 2379) and the peer listener (port 2380), which is exactly what mTLS demands. Combined with --cert-file, --key-file, --trusted-ca-file, --peer-cert-file, --peer-key-file, and --peer-trusted-ca-file, etcd will reject any connection that does not present a certificate signed by the trusted CA. This is the canonical CIS Kubernetes Benchmark configuration for a hardened etcd.

Exam trap

KCSA often tests the misconception that enabling TLS (via cert files or --auto-tls) automatically implies mTLS, when in fact mutual authentication requires the explicit --client-cert-auth and --peer-client-cert-auth flags.

How to eliminate wrong answers

Option A is wrong because --auto-tls=true only auto-generates a self-signed certificate for server-side TLS; it does not enable client certificate authentication, so clients are not mutually authenticated and mTLS is not enforced. Option C is wrong because --insecure-transport=false is not a real etcd flag (the actual flag is --insecure-transport, and disabling it only affects the client listener, not peer mTLS), and HTTP proxy routing has nothing to do with etcd's TLS handshake. Option D is wrong because --cipher-suites only restricts the negotiated TLS cipher suites and does nothing to require client certificates; additionally, TLS_RSA_WITH_AES_128_CBC_SHA is a legacy CBC cipher that is not even in etcd's default Go cipher list and provides no mutual authentication.

Full explanation →
85
MCQeasy

When discussing cloud native security, what does 'ephemeral infrastructure' refer to, and why is it beneficial for security?

A.Network connections that automatically drop after one second
B.Short-lived workloads and nodes that are frequently destroyed and recreated, reducing an attacker's persistence window
C.Virtual machines stored in volatile RAM without disk storage
D.Infrastructure that is permanent and never updated to prevent downtime
AnswerB

Ephemeral infrastructure means nodes and workloads are short-lived, continuously destroyed and recreated rather than patched in place. This shrinks the window in which an attacker can maintain persistence, since compromised instances are routinely replaced, satisfying the stem's security benefit.

Why this answer

Ephemeral infrastructure refers to short-lived workloads and nodes that are frequently destroyed and recreated rather than persisting indefinitely. In cloud native environments, this reduces an attacker's persistence window because any compromise is contained to a brief lifespan, and immutable redeployments wipe out unauthorized changes. This design principle is central to Kubernetes and container security, where pods and nodes are treated as disposable.

Exam trap

The trap here is confusing 'ephemeral' with network or memory characteristics (like short-lived connections or RAM-only VMs) rather than understanding it as a workload lifecycle property that shrinks attacker persistence.

How to eliminate wrong answers

Option A is wrong because it describes a network timeout or connection drop, not infrastructure lifecycle — ephemeral infrastructure is about workload and node lifespan, not packet-level timeouts. Option C is wrong because it describes RAM-only virtual machines (a storage/memory characteristic), not the ephemeral lifecycle concept; ephemeral workloads can still use persistent storage. Option D is wrong because it describes the opposite of ephemeral infrastructure — permanent, never-updated systems increase attack surface and persistence, which is precisely what ephemeral design avoids.

Full explanation →
86
MCQhard

A security analyst reviews an incident where an attacker compromised a container running with the `CAP_SYS_ADMIN` capability and subsequently escaped to the host node. Which cloud native security principle was violated during the initial pod configuration?

A.Zero-trust network architecture
B.Principle of least privilege
C.Shared responsibility model
D.Ephemeral infrastructure design
AnswerB

Granting CAP_SYS_ADMIN to the container gave it excessive privileges, enabling host escape. The principle of least privilege was violated because the pod received far broader capabilities than its workload required, allowing the attacker to escalate to the node.

Why this answer

The principle of least privilege (B) was violated because the container was granted the `CAP_SYS_ADMIN` capability, which is a powerful capability that allows administrative operations. Containers should run with only the minimal capabilities required. Granting such a capability increases the risk of container escape and host compromise.

Exam trap

The trap is selecting a principle that sounds relevant but is not the direct cause. Candidates might choose zero-trust or shared responsibility, but the specific violation is least privilege due to excessive capabilities.

How to eliminate wrong answers

Option A (zero-trust network architecture) is not directly violated; it concerns network segmentation and authentication, not capabilities. Option C (shared responsibility model) is a broader framework, not a specific principle violated by capability assignment. Option D (ephemeral infrastructure design) is about short-lived resources, not about privilege assignment.

Full explanation →
87
MCQeasy

An administrator needs to grant read-only access to Pods specifically within the 'development' namespace to a new user. Which RBAC configuration correctly scopes this permission?

A.Create a ClusterRole for Pod read access and bind it to the user using a RoleBinding in the 'development' namespace.
B.Annotate the user's ServiceAccount with namespace read permissions.
C.Create a Role for Pod read access in the 'development' namespace and bind it to the user using a RoleBinding in the same namespace.
D.Create a Role for Pod read access and bind it globally using a ClusterRoleBinding.
AnswerC

A Role grants permissions within a single namespace, and a RoleBinding in that same namespace ties those permissions to the user. This confines Pod read access to 'development' only, satisfying the namespace-scoped constraint; a ClusterRole with ClusterRoleBinding would grant cluster-wide access instead.

Why this answer

To grant read-only access to Pods within a specific namespace, you create a Role in that namespace with the necessary permissions and bind it to the user using a RoleBinding in the same namespace. This scopes the permission to the 'development' namespace only, following the principle of least privilege.

Exam trap

The trap is confusing Role and ClusterRole, or RoleBinding and ClusterRoleBinding, and incorrectly thinking that a ClusterRoleBinding can be namespace-scoped or that a Role can be bound cluster-wide.

How to eliminate wrong answers

Option A is wrong because while a ClusterRole can be bound with a RoleBinding to limit scope to a namespace, the question asks for the correct RBAC configuration; creating a ClusterRole is unnecessary and less precise than creating a Role directly. However, it is technically valid, but the most correct answer is C because it uses a Role. Option B is wrong because annotating a ServiceAccount does not grant permissions; RBAC requires Role/ClusterRole and RoleBinding/ClusterRoleBinding.

Option D is wrong because binding a Role with a ClusterRoleBinding is not possible; ClusterRoleBinding requires a ClusterRole, and it would grant cluster-wide access, not namespace-scoped.

Full explanation →
88
MCQeasy

You need to restrict network traffic so that only pods with the label 'tier=frontend' can communicate with pods labeled 'tier=backend' in the same namespace. Which Kubernetes resource should you create?

A.NetworkPolicy
B.Ingress
C.FirewallRule
D.Service
AnswerA

A NetworkPolicy selects pods via label selectors and enforces ingress rules at the pod level, permitting traffic only from pods labelled tier=frontend to those labelled tier=backend within the namespace. This directly satisfies the stem's requirement for label-based, namespace-scoped traffic restriction, which Kubernetes NetworkPolicy is purpose-built to provide.

Why this answer

NetworkPolicy is the native Kubernetes resource designed to control pod-to-pod traffic at L3/L4 by selecting pods via label selectors. A NetworkPolicy with a podSelector matching 'tier=backend' and an ingress rule with a podSelector matching 'tier=frontend' restricts ingress to only those pods. This is enforced by the CNI plugin (e.g., Calico, Cilium) on each node.

Exam trap

The trap here is confusing Service (which routes traffic) with NetworkPolicy (which filters traffic) — candidates often pick Service thinking it 'restricts' access, when it actually just load-balances.

How to eliminate wrong answers

Option B is wrong because Ingress manages external HTTP/HTTPS traffic into the cluster (L7 routing to Services), not pod-to-pod communication. Option C is wrong because FirewallRule is not a Kubernetes resource — it is a cloud-provider construct (e.g., Azure/GCP) that operates at the VNet/VPC level, not on pod labels. Option D is wrong because a Service provides stable networking/load balancing to a set of pods but does not enforce any access control or traffic restriction.

Full explanation →
89
MCQhard

An attacker gains execution inside a container that has the `CAP_SYS_ADMIN` capability enabled and shares the host's IPC namespace. How does `CAP_SYS_ADMIN` facilitate container escape?

A.By encrypting all network traffic traversing the CNI plugin bridge
B.By permitting system administration operations like mounting host filesystems and manipulating cgroups
C.By enabling automated horizontal scaling of replica sets
D.By automatically granting cluster-admin Kubernetes RBAC permissions
AnswerB

CAP_SYS_ADMIN grants broad privileged operations, including mounting filesystems and manipulating cgroups. With host IPC shared, an attacker can abuse these to mount the host root filesystem or alter cgroup settings, breaking container isolation and escaping to the host.

Why this answer

CAP_SYS_ADMIN is a powerful Linux capability that grants a broad range of system administration operations, including mounting filesystems, manipulating cgroups, and performing namespace operations. In a container, if this capability is enabled and the container shares the host's IPC namespace, an attacker can mount the host's filesystem (e.g., /dev/sda1) or use cgroup release_agent to execute commands on the host, achieving container escape.

Exam trap

KCSA often tests the misconception that CAP_SYS_ADMIN is a benign or networking-related capability, when in fact it is one of the most dangerous capabilities enabling container escape via mount and cgroup manipulation.

How to eliminate wrong answers

Option A is wrong because CAP_SYS_ADMIN does not encrypt network traffic; encryption is handled by TLS/IPsec and is unrelated to capabilities. Option C is wrong because horizontal scaling is a Kubernetes control-plane function (HPA) and has no relation to Linux capabilities. Option D is wrong because CAP_SYS_ADMIN does not grant Kubernetes RBAC permissions; RBAC is enforced by the API server and is separate from Linux capabilities inside the container.

Full explanation →
90
MCQhard

An attacker gains execution inside a container and attempts to modify the container's root filesystem. The platform team has configured the deployment with `securityContext.readOnlyRootFilesystem: true`. What security mechanism does this enforce?

A.Filesystem immutability and prevention of unauthorized file modifications
B.Automatic container image re-signing
C.Kernel capability escalation blocking
D.Network isolation via NetworkPolicies
AnswerA

Setting readOnlyRootFilesystem mounts the container's root filesystem read-only, so any write attempt by the attacker fails with a filesystem error. This enforces immutability of the container image layers, blocking persistence or tampering within the running container.

Why this answer

Setting `securityContext.readOnlyRootFilesystem: true` in a Kubernetes pod spec mounts the container's root filesystem as read-only, preventing any process inside the container from writing to or modifying files on the root filesystem. This enforces filesystem immutability, which blocks attackers who gain code execution from persisting malware, modifying binaries, or tampering with configuration files. Any write attempt returns an EROFS (Read-only file system) error, forcing attackers to rely on writable volume mounts if any exist.

Exam trap

KCSA often tests the confusion between runtime filesystem controls (readOnlyRootFilesystem) and supply-chain controls (image signing) or network controls (NetworkPolicies), causing candidates to pick a mechanism that operates at a completely different layer of the stack.

How to eliminate wrong answers

Option B is wrong because image re-signing is a supply-chain security function handled by tools like Cosign or Notary, not by a runtime securityContext field — readOnlyRootFilesystem has no cryptographic signing capability. Option C is wrong because kernel capability escalation is controlled by `securityContext.capabilities` (e.g., dropping CAP_SYS_ADMIN) and seccomp/AppArmor profiles, not by filesystem mount flags. Option D is wrong because NetworkPolicies are separate Kubernetes resources that control pod-to-pod traffic at L3/L4; they have no relationship to filesystem mount options in a pod's securityContext.

Full explanation →
91
MCQeasy

A platform engineer wants to configure a container runtime security tool that monitors system calls and sends alerts about potential threats in a Kubernetes cluster. Which component of the container runtime architecture intercepts these system calls?

A.eBPF kernel probes
B.The coreDNS plugin
C.The Kubernetes storage controller
D.The kube-apiserver admission webhook
AnswerA

eBPF probes attach to kernel tracepoints and syscall hooks, letting the runtime security tool observe every system call a container makes without modifying kernel source or loading a module. This satisfies the requirement to intercept syscalls for threat alerting.

Why this answer

eBPF (extended Berkeley Packet Filter) kernel probes are the correct answer because they allow programs to run in the Linux kernel without changing kernel source code or loading modules. In container runtime security, tools like Falco, Tetragon, and Cilium use eBPF to hook into system calls (syscalls) and other kernel events, monitoring container behavior for threats. This interception happens at the kernel level, providing deep visibility into syscalls made by containers.

Exam trap

KCSA often tests the misconception that Kubernetes control plane components like admission webhooks or controllers handle runtime security, confusing API-level policy enforcement with kernel-level syscall monitoring.

How to eliminate wrong answers

Option B is wrong because CoreDNS is a DNS server that provides service discovery in Kubernetes; it does not intercept system calls. Option C is wrong because the Kubernetes storage controller manages persistent volumes and storage classes, not runtime security or syscall monitoring. Option D is wrong because the kube-apiserver admission webhook intercepts API requests to the Kubernetes API server for policy enforcement, not system calls made by containers.

Full explanation →
92
MCQeasy

Which Kubernetes feature allows administrators to define mandatory security baselines, such as disallowing privileged containers, across an entire namespace or cluster?

A.Horizontal Pod Autoscaler
B.PersistentVolume security controller
C.kube-dns policy mapper
D.Pod Security Admission
AnswerD

Pod Security Admission enforces mandatory Pod Security Standards at namespace level via labels, restricting privileged containers and other risky settings cluster-wide. It satisfies the requirement to define baseline security policies across an entire namespace or cluster without per-workload configuration, unlike discretionary controls such as SecurityContext or admission webhooks requiring custom policy code.

Why this answer

Pod Security Admission (PSA) is a built-in Kubernetes admission controller that enforces Pod Security Standards (PSS) at the namespace level. It allows administrators to define mandatory security baselines—such as disallowing privileged containers, hostPath volumes, or host networking—by labeling namespaces with pod-security.kubernetes.io/enforce, audit, or warn modes. PSA replaced the deprecated PodSecurityPolicy and is enabled by default in Kubernetes v1.23+, making it the correct feature for cluster-wide or namespace-scoped security baselines.

Exam trap

KCSA often tests the confusion between Pod Security Admission and the deprecated PodSecurityPolicy (PSP), or between security enforcement and other cluster add-ons like network policies or RBAC, causing candidates to overlook that PSA is the built-in namespace-level baseline enforcer.

How to eliminate wrong answers

Option A is wrong because Horizontal Pod Autoscaler adjusts the number of pod replicas based on CPU/memory or custom metrics; it has no security enforcement role. Option B is wrong because there is no 'PersistentVolume security controller' in Kubernetes—PersistentVolumes are storage abstractions managed by the PV controller, which handles binding and reclaiming, not security baselines. Option C is wrong because kube-dns (CoreDNS) is the cluster DNS add-on responsible for service discovery and name resolution; it has no policy mapping or security enforcement capability.

Full explanation →
93
Multi-Selecthard

Which THREE components are involved when an external client authenticates to the Kubernetes API server using OpenID Connect (OIDC)? (Choose THREE)

Select 3 answers
A.The OIDC Identity Provider (IdP) issuing ID tokens.
B.The CoreDNS server resolving the OIDC provider domain.
C.The client (such as kubectl) presenting the OIDC token in the Authorization header.
D.The Kubelet running on worker nodes.
E.The kube-apiserver configured with OIDC issuer flags.
AnswersA, C, E

The external OIDC provider authenticates the user and issues signed ID tokens containing identity claims. This satisfies the stem's authentication flow because the Kubernetes API server trusts and validates those tokens; without an issuing IdP there is no token for the client to present.

Why this answer

Option A is correct because the OIDC Identity Provider (IdP) is the external authority that authenticates the user and issues the signed ID token (JWT) that the Kubernetes API server will later validate. Option C is correct because the client, such as kubectl, must obtain that ID token and present it to the API server in the HTTP Authorization header as a Bearer token, which is how the credentials reach the API server. Option E is correct because the kube-apiserver must be started with OIDC flags such as --oidc-issuer-url, --oidc-client-id, and --oidc-username-claim so it knows which issuer to trust and how to validate and map the token claims to a Kubernetes user.

Option B is not required for OIDC authentication itself; CoreDNS resolves cluster service names, and while DNS may be needed for general connectivity, it is not a component of the OIDC authentication flow. Option D is also not involved, since the kubelet runs on worker nodes to manage pods and does not participate in authenticating an external client to the API server.

Exam trap

The trap is including infrastructure components like CoreDNS or kubelet that seem plausibly involved in cluster communication but are not part of the OIDC authentication path — focus on IdP, client, and API server.

Full explanation →
94
MCQeasy

Your organization requires that all container images deployed to the production cluster must be scanned for known Common Vulnerabilities and Exposures (CVEs) before admission. Which component in a cloud-native architecture is primarily responsible for intercepting and blocking deployments if a vulnerability threshold is exceeded?

A.The Kubernetes Scheduler
B.An Admission Controller webhook
C.The kube-proxy daemonset
D.The container runtime (e.g., containerd)
AnswerB

Admission controllers sit in the API server request path, so a validating webhook can inspect each pod spec, query the image scanner, and reject the deployment when CVEs exceed the threshold. This satisfies the requirement to block non-compliant images before admission rather than detecting them post-deployment.

Why this answer

Admission Controller webhooks (specifically ValidatingAdmissionWebhooks) intercept API server requests after authentication and authorization but before the object is persisted to etcd. This makes them the correct enforcement point for policies like 'block any pod whose image fails a CVE scan.' Tools such as OPA Gatekeeper, Kyverno, and custom webhooks register with the API server and can reject a Deployment or Pod creation request if the image violates the vulnerability threshold, ensuring non-compliant workloads never reach the scheduler.

Exam trap

KCSA often tests the admission control chain, tricking candidates into choosing the scheduler or runtime — components that act after admission — when the question specifically asks about pre-admission interception and blocking.

How to eliminate wrong answers

Option A is wrong because the Kubernetes Scheduler only decides which node a Pod runs on — it does not evaluate image security or block deployments based on CVE scans. Option C is wrong because kube-proxy is a network component that implements Service abstraction via iptables/IPVS rules; it has no role in admission decisions. Option D is wrong because the container runtime (containerd, CRI-O) pulls and runs images after scheduling — by the time the runtime is involved, the Pod has already been admitted, so it cannot serve as the primary pre-admission gate.

Full explanation →
95
Multi-Selectmedium

Which TWO of the following statements are true regarding Kubernetes Secrets and their security posture by default?

Select 2 answers
A.Mounting a Secret as an environment variable can expose the secret value in container logs or crash dumps.
B.Secrets are strongly encrypted at rest using AES-256 encryption by default in etcd.
C.RBAC can be used to restrict which users and ServiceAccounts can read Secrets within a namespace.
D.Secrets automatically expire and rotate every 30 days unless explicitly disabled.
E.Secrets encoded in base64 provide cryptographic security comparable to robust symmetric encryption.
AnswersA, C

Environment variables are captured in process memory and inherited by child processes, so a crash dump or an application logging its own environment can leak the value. This satisfies the stem's default-posture constraint: Kubernetes applies no masking or redaction to environment-sourced Secrets, unlike mounted volumes, which exist only as files.

Why this answer

Option A is correct because when a Secret is injected via envFrom or valueFrom into a container's environment, the value can leak into application logs, error output, or crash dumps (e.g., core dumps or stack traces), so environment-variable mounting is considered a weaker exposure path than a tmpfs-backed volume mount. Option C is correct because Kubernetes RBAC governs access to the secrets resource via rules on verbs like get, list, and watch, allowing you to limit which Users, Groups, or ServiceAccounts in a namespace can read Secret objects. Option B is wrong because Secrets are only base64-encoded in etcd by default; encryption at rest requires configuring an EncryptionConfiguration with a provider such as aescbc or kms, so AES-256 is not applied by default.

Option D is wrong because Kubernetes Secrets have no built-in expiration or automatic 30-day rotation mechanism; rotation must be implemented externally or via tooling. Option E is wrong because base64 is merely an encoding, not encryption, and provides no confidentiality or cryptographic protection.

Exam trap

The trap is assuming Kubernetes Secrets are encrypted by default — candidates often confuse base64 encoding with encryption and pick option B or E, but the exam tests that you know Secrets are plaintext in etcd unless EncryptionConfiguration is explicitly enabled.

Full explanation →
96
Multi-Selectmedium

Which THREE options represent valid ways to supply sensitive data to a container using Kubernetes native features? (Choose THREE)

Select 3 answers
A.Placing the Secret inside a persistent volume formatted with LUKS encryption.
B.Mounting the Secret as a volume in the Pod specification.
C.Querying the Kubernetes API server directly from the container using a ServiceAccount with proper RBAC.
D.Embedding the Secret plaintext string in the container image build args.
E.Injecting Secret keys as environment variables.
AnswersB, C, E

Projecting a Secret as a volume mounts its keys as files inside the container's filesystem, keeping values out of the image and environment. This is a native Kubernetes mechanism for delivering sensitive data without baking it into the Pod spec.

Why this answer

Option B is correct because Kubernetes natively supports mounting a Secret as a volume in a Pod spec (via volumes.secret and volumeMounts), which projects each key as a file inside the container's filesystem. Option C is correct because a container can use its mounted ServiceAccount token to authenticate to the Kubernetes API server and, with appropriate RBAC permissions, read Secret objects directly via the API. Option E is correct because Secret keys can be injected as environment variables using env.valueFrom.secretKeyRef, a standard native mechanism for passing sensitive data to containers.

Option A is not a Kubernetes-native way to supply Secrets; LUKS-encrypted persistent volumes are an external storage/encryption concern and Secrets are not stored in PVs. Option D is not valid because embedding plaintext secrets in image build args exposes them in image layers and build history, and it is not a Kubernetes Secret delivery mechanism.

Exam trap

The trap here is that candidates pick options that sound secure (LUKS encryption, build args) but are not Kubernetes-native Secret delivery mechanisms — the exam rewards knowing the three built-in paths: volume mount, env var, and API retrieval via ServiceAccount.

Full explanation →
97
Multi-Selecteasy

Which TWO of the following are valid Kubernetes RBAC rule subjects that can be bound to roles or cluster roles?

Select 2 answers
A.Secret
B.User
C.Namespace
D.ServiceAccount
E.PersistentVolume
AnswersB, D

User subjects bind RBAC roles to named human accounts, satisfying the stem's requirement for a valid subject type. Kubernetes authorises requests by matching the authenticated username against RoleBinding or ClusterRoleBinding subjects, and Microsoft Entra ID–backed clusters surface that identity as a User entry.

Why this answer

Option B (User) is correct because Kubernetes RBAC subjects include User, Group, and ServiceAccount, and a User subject is identified by a string name (often an email or certificate CN) in a RoleBinding or ClusterRoleBinding. Option D (ServiceAccount) is correct because ServiceAccount is a first-class RBAC subject, specified with its name and namespace (e.g., system:serviceaccount:<namespace>:<name>) when binding a Role or ClusterRole. Options A (Secret), C (Namespace), and E (PersistentVolume) are not RBAC subjects; they are Kubernetes API resource kinds that can appear in a Role/ClusterRole's rules as resources, but they cannot be bound as the subject of a RoleBinding or ClusterRoleBinding.

Exam trap

KCSA often tests the distinction between RBAC subjects and RBAC resources — candidates see 'Secret,' 'Namespace,' or 'PersistentVolume' and forget that subjects must be identities (User, Group, ServiceAccount), not API objects.

Full explanation →
98
Multi-Selecthard

Which TWO of the following API server configuration flags help enforce cryptographic and transport security? (Choose TWO)

Select 2 answers
A.--tls-cipher-suites to specify permitted strong cryptographic cipher suites.
B.--tls-min-version to enforce a minimum acceptable TLS protocol version.
C.--anonymous-auth to enable unauthenticated cluster access.
D.--insecure-port to allow unencrypted HTTP traffic.
E.--enable-http2=false to disable secure multiplexing.
AnswersA, B

The flag restricts the API server to an explicit allowlist of strong cipher suites, preventing negotiation of weak or deprecated algorithms during TLS handshakes. This directly enforces the cryptographic security constraint in the stem by hardening transport encryption for client and component connections.

Why this answer

Option A, --tls-cipher-suites, is correct because it lets you restrict the API server to a defined list of strong, permitted TLS cipher suites, preventing negotiation of weak or deprecated ciphers and thereby hardening cryptographic security. Option B, --tls-min-version, is correct because it sets the minimum acceptable TLS protocol version (for example VersionTLS12), ensuring clients cannot downgrade to older, vulnerable TLS versions. Together these flags directly enforce cryptographic strength and transport-layer security on the kube-apiserver.

Option C, --anonymous-auth, is wrong because enabling unauthenticated access weakens security rather than enforcing it. Option D, --insecure-port, is wrong because it permits unencrypted HTTP traffic, the opposite of transport security. Option E, --enable-http2=false, is wrong because disabling HTTP/2 does not enforce cryptographic or transport security and is not a security-hardening flag for this purpose.

Exam trap

KCSA often tests whether candidates confuse flags that weaken security (--anonymous-auth, --insecure-port) with flags that strengthen it (--tls-cipher-suites, --tls-min-version), so read each flag's effect carefully rather than pattern-matching on the word 'TLS'.

Full explanation →
99
MCQhard

A security engineer is hardening a Kubernetes cluster against container breakout attacks. They configure AppArmor profiles and ensure pods run with a non-root user. Which of the 4Cs layers are these security measures primarily designed to protect?

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

AppArmor profiles and non-root user enforcement operate at the Container layer, satisfying the stem's container breakout constraint. These controls restrict syscalls and privilege escalation within individual containers, directly mitigating breakout attempts. The Cloud, Cluster, and Code layers address different concerns, so Container is the correct 4Cs layer here.

Why this answer

AppArmor profiles and running pods as a non-root user are security measures that apply to the container runtime and the containerized processes. These controls restrict what a container can do, such as limiting system calls or preventing privilege escalation, which are part of the Container layer in the 4Cs model. Therefore, the Container layer is the primary target.

Exam trap

KCSA often tests the 4Cs layers, and candidates may confuse Container layer controls with Cluster layer controls because both involve security configurations, but the key is that Container layer is about the container runtime and its processes.

How to eliminate wrong answers

Option A is wrong because the Cluster layer focuses on securing the Kubernetes control plane, nodes, and cluster-wide policies, not individual container runtime restrictions. Option C is wrong because the Cloud layer pertains to the underlying cloud infrastructure and services, such as network and IAM, not container-level controls. Option D is wrong because the Code layer is about the application code itself, including secure coding and dependencies, not runtime container security.

Full explanation →
100
MCQeasy

Which CNCF project acts as a cloud-native runtime security and intrusion detection tool that monitors system calls against predefined security rules?

A.Trivy
B.Fluentd
C.Falco
D.Cert-manager
AnswerC

Falco is the CNCF runtime security project that instruments kernel system calls, evaluating them against a rule set to detect anomalous or malicious container behaviour. It satisfies the stem's requirement for runtime intrusion detection monitoring syscalls against predefined rules.

Why this answer

Falco is the CNCF-graduated cloud-native runtime security project that detects anomalous activity and intrusions by monitoring Linux system calls (and Kubernetes audit events) against a rule engine. It uses a kernel module or eBPF probe to capture syscalls and evaluates them against YAML-defined rules, generating alerts when behavior matches known attack patterns. This makes it the canonical answer for runtime threat detection in Kubernetes environments.

Exam trap

The trap is confusing scanning tools with runtime detection tools — candidates may pick Trivy because it is security-related, but Trivy scans images statically while Falco monitors live syscalls, which is what 'runtime security and intrusion detection' specifically requires.

How to eliminate wrong answers

Option A is wrong because Trivy is a vulnerability and misconfiguration scanner for container images, filesystems, and IaC — it performs static analysis, not runtime syscall monitoring. Option B is wrong because Fluentd is a log collection and forwarding agent (part of the observability stack), not a security rule engine that inspects syscalls. Option D is wrong because cert-manager automates X.509 certificate issuance and renewal (e.g., via Let's Encrypt or Vault) — it has nothing to do with runtime intrusion detection.

Full explanation →
101
Multi-Selecthard

Which THREE of the following configurations or features represent critical attack vectors or misconfigurations in a Kubernetes cluster threat model?

Select 3 answers
A.Mounting the host Docker socket (`/var/run/docker.sock`) into application pods
B.Exposing the unauthenticated Kubelet read-only port (10255)
C.Enabling Pod Security Admission in restricted mode across all namespaces
D.Running application pods with `securityContext.privileged: true`
E.Configuring etcd encryption at rest with a Secret encryption provider
AnswersA, B, D

Mounting the host Docker socket gives a pod control over the container runtime, enabling container creation with host mounts or privileged access, effectively escaping to the node. This represents a critical attack vector in the cluster threat model.

Why this answer

Option A is correct because mounting /var/run/docker.sock into a pod gives the container direct control over the host's Docker daemon, allowing an attacker to create privileged containers, mount host filesystems, or escape to the node. Option B is correct because the Kubelet read-only port 10255 serves unauthenticated and unencrypted API data, exposing pod specs, environment variables, and cluster details to anyone who can reach the node. Option D is correct because securityContext.privileged: true disables container isolation, granting all Linux capabilities and host device access, which makes node compromise and container escape trivial.

Option C is not a vector because Pod Security Admission in restricted mode is a hardening control that enforces least-privilege pod settings. Option E is not a vector because etcd encryption at rest with a Secret encryption provider protects sensitive data in etcd rather than exposing it.

Exam trap

KCSA often tests the ability to distinguish hardening controls (Pod Security Admission, etcd encryption) from attack vectors (host socket mounts, exposed Kubelet ports, privileged pods) — candidates must read whether the question asks for risks or mitigations.

Full explanation →
102
MCQeasy

You are auditing a cluster and find a pod that mounts the host's root filesystem directly into the container. Which Pod Security Standard rule does this violate?

A.It is permitted under all standards provided the container runs as a non-root user.
B.It violates both baseline and restricted standards by using a hostPath volume.
C.It is fully compliant with the restricted standard as long as 'readOnly: true' is set.
D.It only violates the restricted standard; baseline permits hostPath mounts.
AnswerB

Mounting the host root filesystem uses a hostPath volume, which the baseline standard forbids and the restricted standard also prohibits. The pod therefore breaches both standards, satisfying the audit finding that hostPath is the violating mechanism.

Why this answer

Mounting the host's root filesystem via a hostPath volume violates both the baseline and restricted Pod Security Standards. The baseline standard prohibits hostPath volumes (except for a few specific, safe paths), and the restricted standard prohibits them entirely. Therefore, this pod violates both.

Exam trap

KCSA often tests the specific differences between baseline and restricted Pod Security Standards, and candidates may incorrectly assume that readOnly: true makes hostPath compliant or that baseline allows any hostPath.

How to eliminate wrong answers

Option A is wrong because hostPath volumes are not permitted under all standards even if the container runs as non-root; the baseline and restricted standards explicitly restrict hostPath. Option C is wrong because the restricted standard does not permit hostPath volumes even with readOnly: true; readOnly does not make it compliant. Option D is wrong because baseline does not permit hostPath mounts (except for a limited set of paths like /proc, /sys, etc., but not the host root filesystem); thus it violates baseline as well.

Full explanation →
103
MCQeasy

When configuring a Pod to run securely, which setting in the container's securityContext should be used to explicitly drop all default Linux capabilities and only retain required ones?

A.capabilities.drop: ["ALL"]
B.runAsNonRoot: true
C.capabilities.add: ["ALL"]
D.privileged: true
AnswerA

Dropping ALL first removes every default capability, then specific ones can be added back via capabilities.add. This satisfies the stem's requirement to explicitly drop all defaults while retaining only what the container genuinely needs, following least privilege.

Why this answer

In the container's securityContext, capabilities.drop: ["ALL"] removes every default Linux capability (like NET_RAW, CHOWN, SETUID) from the container process, after which you can selectively add back only what the workload needs via capabilities.add. This follows the principle of least privilege and is the canonical hardening pattern for Pods.

Exam trap

KCSA often tests whether candidates conflate runAsNonRoot with capability dropping — both are securityContext settings, but only capabilities.drop: ["ALL"] removes Linux capabilities.

How to eliminate wrong answers

Option B is wrong because runAsNonRoot only enforces that the container does not run as UID 0 — it does not touch Linux capabilities at all. Option C is wrong because capabilities.add: ["ALL"] grants every capability, which is the opposite of least privilege and effectively equivalent to privileged mode. Option D is wrong because privileged: true disables all capability restrictions and gives the container full access to the host, which is the least secure setting possible.

Full explanation →
104
Multi-Selecteasy

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

Select 3 answers
A.Granting wildcard cluster-admin permissions to untrusted service accounts.
B.Enabling anonymous authentication on the API server or kubelet.
C.Configuring kubelet authorization mode to Webhook.
D.Enabling etcd encryption at rest with a valid key.
E.Leaving the API server insecure port (--insecure-port) enabled.
AnswersA, B, E

Wildcard cluster-admin grants untrusted service accounts unrestricted access across every resource and namespace, letting compromised workloads read secrets, alter workloads, or disable controls. This directly satisfies the stem's control-plane compromise scenario by removing least-privilege boundaries.

Why this answer

Option A is correct because binding a service account to a ClusterRole with wildcard verbs/resources (e.g., via ClusterRoleBinding to cluster-admin) lets any pod using that account read secrets, create privileged workloads, and effectively take over the control plane. Option B is correct because enabling anonymous authentication (--anonymous-auth=true) on the API server or kubelet allows unauthenticated requests to reach endpoints, and combined with permissive authorization it exposes cluster data and node operations to anyone who can reach the port. Option E is correct because the API server's insecure port (--insecure-port) serves requests over plain HTTP with no authentication or authorization, so any network-reachable client can issue privileged API calls.

Option C is not a compromise: Webhook authorization mode delegates decisions to the API server's SubjectAccessReview, which is the recommended secure mode for kubelet. Option D is not a compromise: encrypting etcd at rest with a valid key protects secret data and is a security best practice, not a risk.

Exam trap

KCSA often tests whether candidates can distinguish security-hardening controls (Webhook authorization, etcd encryption) from actual misconfigurations — the trap is picking a best-practice option as if it were a risk.

Full explanation →
105
MCQhard

A security incident response team discovers that a vulnerability in a third-party Python library allowed remote code execution inside a pod. In the context of defense-in-depth and the 4Cs, which layer primarily failed or was unmitigated, requiring remediation at the source?

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

The vulnerable Python library executes within the container's application code, so the flaw originates at the Code layer of the 4Cs. Remediation belongs at source: patching or upgrading the dependency, since node, cluster and cloud layers did not introduce the remote code execution flaw.

Why this answer

A vulnerability in a third-party Python library that enables RCE inside a pod is a Code-layer failure. The Code layer encompasses application code, dependencies, libraries, and the software supply chain. Remediation must occur at the source — patching or replacing the vulnerable library, scanning dependencies, and rebuilding the image — because the flaw originates in the application's code/dependency stack, not in the cluster or container runtime.

Exam trap

KCSA often tests the distinction between the Container layer and the Code layer — candidates see 'inside a pod' and pick Container, but the root cause (third-party library) belongs to the Code layer, and remediation must happen at the source.

How to eliminate wrong answers

Option A is wrong because the Cloud layer covers infrastructure and provider controls, not application dependencies. Option B is wrong because the Cluster layer covers Kubernetes control plane and node components (API server, kubelet, RBAC), not Python libraries inside a pod. Option C is wrong because the Container layer covers the runtime, image integrity, and isolation primitives — while the image may need rebuilding, the root cause is the vulnerable library in the Code layer.

Full explanation →
106
MCQhard

You have configured a NetworkPolicy with an egress rule targeting a specific CIDR block. However, DNS resolution for external domain names fails from within the pods selected by this policy. What is the most likely cause?

A.NetworkPolicies automatically disable CoreDNS across the entire namespace.
B.DNS packets are rejected because they do not contain IP block headers.
C.The external domain name does not have a corresponding Service object.
D.Outgoing DNS traffic on UDP/TCP port 53 to the cluster DNS server was blocked by the default-deny egress behavior.
AnswerD

A default-deny egress policy blocks all outbound traffic, including UDP and TCP port 53 queries to the cluster DNS service. Without an explicit egress rule permitting DNS, pods cannot resolve external domain names even though the CIDR rule allows other destinations.

Why this answer

When a NetworkPolicy with egress rules is applied, it acts as a default-deny for all egress traffic except what is explicitly allowed. DNS resolution requires egress to the cluster DNS service (often CoreDNS) on UDP/TCP port 53. If that traffic is not allowed, DNS queries fail, causing resolution errors.

Exam trap

KCSA often tests NetworkPolicy egress rules, and candidates may overlook the need to explicitly allow DNS traffic, assuming DNS is always permitted.

How to eliminate wrong answers

Option A is wrong because NetworkPolicies do not disable CoreDNS; they only control traffic to and from selected pods. Option B is wrong because DNS packets are UDP/TCP and do not have IP block headers; the issue is port/protocol blocking. Option C is wrong because external domain names do not require a Service object; DNS resolution is about querying the DNS server, not about Services.

Full explanation →
107
MCQeasy

According to the shared responsibility model for a cloud-managed Kubernetes service, who is responsible for managing application data encryption keys (using KMS) and application-level secrets?

A.The cloud provider
B.The customer
C.The Linux Foundation
D.The container runtime vendor
AnswerB

KMS key management and application-level secrets sit in the customer's data and identity domain, not the provider's managed infrastructure. The provider secures the platform; the customer controls encryption keys and secret material for their workloads.

Why this answer

Under the shared responsibility model for managed Kubernetes (EKS, AKS, GKE), the cloud provider secures the control plane and physical infrastructure, but the customer always owns their data and the keys protecting it. Application data encryption keys managed via KMS and application-level secrets (API keys, DB credentials, tokens) remain the customer's responsibility regardless of service model.

Exam trap

The trap here is assuming 'managed' means 'fully managed' — candidates over-attribute security duties to the cloud provider and forget that data, secrets, and encryption keys always remain the customer's responsibility.

How to eliminate wrong answers

Option A is wrong because the cloud provider manages the control plane, nodes (in managed node pools), and physical security — not customer application data or its encryption keys. Option C is wrong because the Linux Foundation is a standards/governance body (CNCF parent), not a party in the operational shared responsibility model. Option D is wrong because the container runtime vendor supplies the runtime software (containerd, CRI-O) but has no operational responsibility for customer secrets or KMS keys.

Full explanation →
108
MCQmedium

A security auditor notices that a deployment running in the 'production' namespace is violating the Restricted Pod Security Standard because containers are running as root. How can you enforce compliance using Pod Security Admission?

A.Label the 'production' namespace with 'pod-security.kubernetes.io/enforce=restricted'.
B.Create a NetworkPolicy that blocks root user communication.
C.Enable the SecurityContextDeny legacy admission controller.
D.Update the kube-apiserver flags to globally block non-restricted pods without namespace labels.
AnswerA

Applying the enforce label with the restricted value makes Pod Security Admission actively reject pods that violate the Restricted standard, including root-running containers. This directly enforces compliance in the production namespace rather than merely warning or auditing.

Why this answer

Pod Security Admission is enforced per-namespace via labels, and the label 'pod-security.kubernetes.io/enforce=restricted' applies the Restricted Pod Security Standard to every pod created in that namespace, rejecting non-compliant pods such as those running as root. This is the native, supported mechanism in Kubernetes 1.25+ after PodSecurityPolicy was removed.

Exam trap

KCSA often tests the misconception that Pod Security Admission can be configured globally via apiserver flags or replaced by NetworkPolicy — candidates who don't know PSA is namespace-label driven pick B or D.

How to eliminate wrong answers

Option B is wrong because NetworkPolicy operates at L3/L4 and has no concept of user IDs or root — it cannot enforce runAsNonRoot or any security context setting. Option C is wrong because SecurityContextDeny is a deprecated legacy admission controller that was removed in Kubernetes 1.13 and never enforced the full Restricted PSS. Option D is wrong because Pod Security Admission is namespace-label driven by design; there is no kube-apiserver flag that globally enforces a PSS profile without namespace labels, and modifying apiserver flags is not how PSA is configured.

Full explanation →
109
MCQeasy

When configuring a container to run securely in a Kubernetes cluster, you want to ensure that the container process cannot gain any new privileges during its lifecycle, even if it runs as root or exploits a setuid binary. Which Linux kernel feature should be enabled in the container security context?

A.readOnlyRootFilesystem: false
B.allowPrivilegeEscalation: false
C.privileged: true
D.runAsNonRoot: false
AnswerB

Setting `allowPrivilegeEscalation: false` applies the kernel's `no_new_privs` flag to the container process, preventing it from gaining additional privileges through setuid or setgid binaries, file capabilities, or similar mechanisms. This satisfies the stem's requirement that no new privileges can be acquired during the container's lifecycle, even when running as root.

Why this answer

The allowPrivilegeEscalation: false setting directly controls whether a container process can gain more privileges than its parent process. It sets the Linux no_new_privs flag on the container process, which prevents setuid/setgid binaries and file capabilities from elevating privileges. This is the exact kernel feature that blocks privilege escalation even when running as root.

Exam trap

KCSA often tests the confusion between runAsNonRoot and allowPrivilegeEscalation — candidates mistakenly think that running as non-root alone prevents privilege escalation, but setuid binaries can still elevate privileges without no_new_privs.

How to eliminate wrong answers

Option A is wrong because readOnlyRootFilesystem: false actually disables the read-only root filesystem protection, which is unrelated to privilege escalation and would weaken security. Option C is wrong because privileged: true grants the container nearly all host capabilities and device access, which is the opposite of restricting privilege escalation. Option D is wrong because runAsNonRoot: false merely permits running as root; it does not prevent a process from gaining new privileges via setuid binaries or capabilities.

Full explanation →
110
MCQeasy

A developer configures a Kubernetes Pod with `hostNetwork: true`. Under the STRIDE threat model, which threat category is most directly introduced or elevated by this configuration?

A.Denial of Service via CPU exhaustion
B.Tampering of container image layers at rest
C.Elevation of Privilege and Information Disclosure
D.Repudiation of database audit logs
AnswerC

Sharing the host network namespace removes isolation, letting the Pod sniff node traffic and reach loopback-bound services, which is Information Disclosure. Combined with root or privileged capabilities, it also permits spoofing and bypassing network policy, elevating privilege on the node.

Why this answer

Setting hostNetwork: true places the Pod directly in the host's network namespace, so it shares the node's IP, routing table, and can bind to any host port — including privileged ports and ports used by node services. This directly elevates privilege (the Pod can sniff or interfere with node-level traffic and reach services bound to localhost) and discloses information (it can observe host network traffic and access node-local endpoints). Under STRIDE, these map to Elevation of Privilege and Information Disclosure.

Exam trap

The trap is that candidates pick a generic DoS or image-integrity answer because they associate 'host' with resource or storage risk, missing that hostNetwork's core STRIDE impact is privilege elevation plus information disclosure via the shared node network namespace.

How to eliminate wrong answers

Option A is wrong because CPU exhaustion is a resource-exhaustion/DoS concern addressed by resource requests and limits, not specifically introduced by hostNetwork — hostNetwork does not grant CPU priority. Option B is wrong because tampering with container image layers at rest is a registry/storage integrity concern (e.g., image signing, admission control), unrelated to network namespace sharing. Option D is wrong because repudiation of database audit logs concerns logging and non-repudiation controls, not network namespace configuration.

Full explanation →
111
MCQmedium

An auditor notices that kubelet authentication is set to always allow anonymous access in a cluster configuration. According to the CIS Benchmark, what should the kubelet configuration parameter "authentication.anonymous.enabled" be set to?

A.strict
B.auto
C.true
D.false
AnswerD

Setting `authentication.anonymous.enabled` to false disables unauthenticated requests to the kubelet API, satisfying the CIS Benchmark requirement that anonymous access be eliminated. This closes the exposure the auditor identified, forcing every request to authenticate via client certificates or bearer tokens before the kubelet processes it.

Why this answer

The CIS Kubernetes Benchmark explicitly requires that anonymous authentication to the kubelet be disabled. Setting authentication.anonymous.enabled to false ensures that unauthenticated requests to the kubelet's HTTPS endpoint are rejected, forcing all clients to authenticate. This prevents unauthorized users or workloads from querying sensitive node information or executing commands via the kubelet API.

Exam trap

KCSA often tests the misconception that 'strict' or 'auto' are valid boolean values for kubelet authentication settings, when in fact the parameter expects true or false, and the secure setting is false.

How to eliminate wrong answers

Option A is wrong because 'strict' is not a valid value for authentication.anonymous.enabled; it is a boolean field, and 'strict' might be confused with authentication.webhook.enabled or authorization modes. Option B is wrong because 'auto' is not a valid boolean value and does not correspond to any kubelet authentication setting. Option C is wrong because setting it to true would enable anonymous access, which directly violates the CIS Benchmark recommendation and exposes the kubelet to unauthenticated requests.

Full explanation →
112
MCQmedium

An administrator notices that unauthorized users can view sensitive ConfigMaps across different namespaces because default RoleBindings were overly permissive. Which security principle was violated?

A.Least privilege access
B.Shared responsibility model
C.Immutable infrastructure
D.Supply chain security
AnswerA

Least privilege means each user and service account gets only the permissions its task needs, in the narrowest scope. Bindings that let users read ConfigMaps across namespaces they do not work in break that. Use namespaced Roles and RoleBindings instead of broad ClusterRoleBindings, avoid wildcards, and audit with 'kubectl auth can-i --list --as <user> -n <namespace>'. Sensitive values belong in Secrets, not ConfigMaps.

Why this answer

Overly permissive default RoleBindings that allow unauthorized users to view ConfigMaps across namespaces violate the principle of least privilege. Least privilege requires granting only the minimum permissions necessary for a user or service to perform its function. Default RoleBindings that grant broad read access to ConfigMaps across namespaces exceed that minimum and expose sensitive configuration data.

Exam trap

KCSA often tests the distinction between least privilege and other security principles — candidates may pick 'shared responsibility' because it sounds like a governance issue, but the specific violation of granting more access than needed is least privilege.

How to eliminate wrong answers

Option B is wrong because the shared responsibility model defines which party (cloud provider vs. customer) secures which layer — it does not describe access control violations. Option C is wrong because immutable infrastructure means replacing rather than modifying servers, which is unrelated to RBAC permissions. Option D is wrong because supply chain security concerns the integrity of software artifacts and dependencies, not namespace-level RBAC misconfigurations.

Full explanation →
113
Multi-Selectmedium

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

Select 2 answers
A.Shift-left security, integrating security checks early into the development and CI/CD pipeline.
B.Hardcoding administrative credentials directly into source code for operational simplicity.
C.Implicit trust of internal microservices communicating within the same cluster network.
D.Defense-in-depth, implementing multiple overlapping security controls across the 4Cs.
E.Perimeter-only defense, relying exclusively on an external corporate firewall.
AnswersA, D

Shift-left moves security controls into earlier development phases, embedding scanning, policy checks and testing into CI/CD pipelines. This catches misconfigurations and vulnerabilities before deployment, reducing remediation cost and satisfying cloud native security's emphasis on securing the software supply chain.

Why this answer

Option A is correct because shift-left security is a foundational cloud native principle: security checks (SAST, SCA, container image scanning, IaC validation) are integrated early into development and the CI/CD pipeline so vulnerabilities are caught before deployment rather than after. Option D is correct because defense-in-depth is a core tenet of cloud native security, layering overlapping controls across the 4Cs (Cloud, Cluster, Container, Code) so that no single control failure compromises the workload. Option B is wrong because hardcoding administrative credentials in source code violates secrets management and least-privilege practices, creating a critical vulnerability rather than a security principle.

Option C is wrong because implicit trust between microservices is an anti-pattern; cloud native security requires zero-trust, mutual authentication (e.g., mTLS) and explicit authorization between services. Option E is wrong because perimeter-only defense assumes a hard outer shell with a soft interior, which fails against lateral movement, insider threats, and compromised workloads in dynamic cloud environments.

Exam trap

KCSA often tests whether candidates recognize that implicit trust and perimeter-only defense are outdated models — the exam presents them as plausible options to catch those who haven't internalized zero-trust and defense-in-depth.

Full explanation →
114
MCQhard

An application pod requires access to the Kubernetes API to list other pods. To follow secure practices, you create a dedicated ServiceAccount and bind a custom Role to it. How should you configure the Pod specification to prevent the default service account token from being automatically mounted?

A.Delete the 'default' ServiceAccount in the namespace.
B.Set 'automountServiceAccountToken: false' in the Pod specification.
C.Configure the Pod securityContext with 'readOnlyRootFilesystem: true'.
D.Add a deny NetworkPolicy blocking egress to the Kubernetes API service IP.
AnswerB

Setting automountServiceAccountToken to false in the Pod specification stops Kubernetes injecting the default ServiceAccount token, so the pod uses only its dedicated ServiceAccount credentials. This removes an unnecessary, broadly permissioned token from the pod's filesystem.

Why this answer

Setting automountServiceAccountToken: false in the Pod spec prevents Kubernetes from automatically projecting the ServiceAccount token into the pod's filesystem. This is the correct way to stop the default token mount while still allowing the pod to use a dedicated ServiceAccount for API access when needed. The pod can still explicitly mount a token if required, but automatic mounting is disabled.

Exam trap

KCSA often tests whether candidates know that automountServiceAccountToken is the direct control for token mounting, while securityContext and NetworkPolicy address unrelated concerns — don't pick filesystem or network hardening for a token-mounting question.

How to eliminate wrong answers

Option A is wrong because deleting the default ServiceAccount is disruptive and unnecessary; Kubernetes recreates it, and it does not control per-pod token mounting. Option C is wrong because readOnlyRootFilesystem hardens the container filesystem but has no effect on whether the ServiceAccount token is mounted. Option D is wrong because a NetworkPolicy blocking egress to the API server IP prevents network access but does not stop the token from being mounted into the pod, and it would also break legitimate API calls the app needs.

Full explanation →
115
Multi-Selectmedium

Which TWO methods can be used to restrict network traffic between services inside a service mesh? (Choose two)

Select 2 answers
A.Modifying CoreDNS forwarding upstream servers
B.PeerAuthentication resources enforcing STRICT mTLS mode between workloads
C.Configuring Horizontal Pod Autoscalers
D.Kubernetes PersistentVolumeClaim storage resize operations
E.Istio AuthorizationPolicy resources specifying allowed source principals and methods
AnswersB, E

PeerAuthentication with STRICT mTLS mode satisfies the in-mesh traffic restriction constraint by cryptographically authenticating workloads and rejecting plaintext connections. It enforces mutual TLS at the transport layer, so only workloads presenting valid SPIFFE identities from the mesh's certificate authority can communicate, blocking unauthenticated or spoofed traffic between services.

Why this answer

Option B is correct because PeerAuthentication with mode STRICT enforces mutual TLS between workloads, so only identities holding a valid SPIFFE certificate issued by the mesh CA can complete the TLS handshake, effectively blocking plaintext or non-mesh traffic to those pods. Option E is correct because Istio AuthorizationPolicy resources let you define allow/deny rules based on source principals (SPIFFE identities), namespaces, HTTP methods, paths, and ports, which directly restricts which services may talk to which others inside the mesh. Option A is wrong because CoreDNS forwarding upstream servers only affects name resolution for external domains, not intra-mesh traffic filtering.

Option C is wrong because Horizontal Pod Autoscalers adjust replica counts based on metrics and do not enforce any traffic restrictions. Option D is wrong because PersistentVolumeClaim resize operations change storage capacity and have no bearing on network traffic between services.

Exam trap

KCSA often tests the confusion between network-level restrictions (like mTLS and authorization policies) and unrelated operational controls such as DNS, autoscaling, or storage, so candidates must recognize that only identity-based mesh policies restrict service-to-service traffic.

Full explanation →
116
MCQeasy

A cluster administrator needs to grant read-only access to pods within the 'development' namespace using Kubernetes RBAC. Which resource kind should be used to define the permissions?

A.SecurityContextConstraints
B.Role
C.PodSecurityPolicy
D.ClusterRole
AnswerB

A Role defines permissions scoped to a single namespace, so it grants read-only pod access within 'development' only. ClusterRole would apply cluster-wide, breaching the namespace constraint. Binding the Role via RoleBinding to the intended subjects completes the RBAC grant.

Why this answer

A Role is a namespaced Kubernetes resource that defines permissions within a specific namespace. Since the requirement is to grant read-only access to pods in the 'development' namespace, a Role scoped to that namespace is the correct choice. It can be bound to a user, group, or service account via a RoleBinding to grant the necessary permissions.

Exam trap

KCSA often tests the difference between namespaced and cluster-scoped RBAC resources, and candidates may incorrectly choose ClusterRole thinking it is required for any permission, or confuse SecurityContextConstraints with RBAC.

How to eliminate wrong answers

Option A is wrong because SecurityContextConstraints (SCCs) are OpenShift-specific resources that control pod security policies, not RBAC permissions for accessing pods. Option C is wrong because PodSecurityPolicy (deprecated in Kubernetes 1.21 and removed in 1.25) was used to control pod security settings, not to grant read access to pods. Option D is wrong because a ClusterRole is cluster-scoped and grants permissions across all namespaces; while it could be used with a RoleBinding to grant access within a namespace, it is not the most precise resource for namespace-specific permissions and is typically used for cluster-wide access or for defining reusable permissions.

Full explanation →
117
Multi-Selecthard

An enterprise is conducting a security review of their container build and deployment pipeline. Which TWO security controls should they implement to secure the Container layer? (Choose TWO)

Select 2 answers
A.Scanning container images for known CVEs before deployment
B.Enforcing non-root execution and secure container security contexts
C.Writing application unit tests in Python or Go
D.Procuring dedicated physical server racks from the cloud provider
E.Writing Terraform scripts to provision AWS VPCs
AnswersA, B

Scanning images for known CVEs before deployment removes vulnerable packages from the container layer, satisfying the stem's container-layer control requirement. It catches flaws at build time rather than relying on runtime detection after workloads are already scheduled.

Why this answer

Option A is correct because scanning container images for known CVEs before deployment (e.g., with Trivy, Clair, or Grype) detects vulnerable OS packages and application dependencies in image layers, preventing exploitable images from reaching the registry or runtime. Option B is correct because enforcing non-root execution and secure container security contexts (via runAsNonRoot, readOnlyRootFilesystem, dropped Linux capabilities, and seccomp/AppArmor profiles) reduces the impact of a container compromise by limiting privileges and blocking privilege-escalation paths. Option C is incorrect because unit tests in Python or Go verify application logic, not container-layer security controls.

Option D is incorrect because dedicated physical server racks address physical infrastructure isolation, not the container layer. Option E is incorrect because Terraform scripts provisioning AWS VPCs secure the network layer, not the container layer itself.

Exam trap

KCSA often tests the distinction between container-layer controls (image scanning, security contexts) and other layers (code, cluster, infrastructure), so candidates may mistakenly choose application testing or infrastructure provisioning as container security measures.

Full explanation →
118
MCQeasy

When evaluating cloud native security principles, why is reliance on a traditional network firewall (perimeter security) considered insufficient for modern Kubernetes environments?

A.Because Kubernetes natively disables all network traffic by default
B.Because cloud providers prohibit the use of firewalls
C.Because container workloads have dynamic IP addresses and high east-west traffic that perimeter firewalls cannot inspect effectively
D.Because firewalls cannot run on Linux operating systems
AnswerC

Pods receive ephemeral IP addresses and communicate heavily east-west between services, traffic that never crosses the perimeter. Firewalls therefore cannot inspect or attribute these flows, making them insufficient for Kubernetes environments where identity-based, workload-level controls are required instead.

Why this answer

Kubernetes pods receive ephemeral IPs from the CNI plugin and are constantly created, destroyed, and rescheduled, so static perimeter firewall rules cannot reliably identify or track workloads. Additionally, most traffic in a cluster is east-west (pod-to-pod, service-to-service), which never crosses the perimeter and therefore is invisible to a traditional firewall. This is why Kubernetes-native controls like NetworkPolicies, service meshes, and zero-trust identity are required.

Exam trap

KCSA often tests the misconception that firewalls are useless or unsupported in cloud/Kubernetes, when the real point is that perimeter firewalls lack visibility into dynamic, east-west container traffic — candidates must distinguish 'insufficient' from 'impossible'.

How to eliminate wrong answers

Option A is wrong because Kubernetes does not disable network traffic by default — in fact, absent NetworkPolicies, all pod-to-pod traffic is allowed (a flat network), which is the opposite of the claim. Option B is wrong because cloud providers fully support firewalls (security groups, NACLs, cloud firewalls); they do not prohibit them. Option D is wrong because firewalls absolutely run on Linux — iptables, nftables, and pfSense are Linux-based, and Kubernetes itself uses iptables/IPVS rules for service routing.

Full explanation →
119
MCQeasy

Why should container images be built using multi-stage builds in Dockerfiles from a security perspective?

A.They encrypt the container image layer storage in the registry
B.They automatically enable kernel-level eBPF monitoring
C.They exclude build-time tools, package managers, and source code from the final production image, reducing attack surface
D.They enforce mTLS encryption for all container network traffic
AnswerC

Multi-stage builds let the final stage copy only compiled artefacts, so compilers, package managers and source code never reach the production image. This directly satisfies the security goal of a minimal runtime footprint, shrinking the attack surface available to an attacker who compromises the running container.

Why this answer

Multi-stage builds let you use one stage (with compilers, package managers, source code, and build tools) to produce artifacts, then copy only the final binaries into a minimal runtime stage. The production image therefore excludes build-time tooling and source, shrinking the attack surface and eliminating many CVEs that come from build dependencies.

Exam trap

The trap is confusing build-time hygiene (multi-stage builds) with runtime or network security controls — candidates pick options mentioning encryption or monitoring because they sound security-related.

How to eliminate wrong answers

Option A is wrong because multi-stage builds have nothing to do with registry-side encryption — that is handled by registry features like OCI encryption or TLS. Option B is wrong because eBPF monitoring is a runtime kernel feature enabled by tools like Cilium or Falco, not by Dockerfile structure. Option D is wrong because mTLS is a network-layer concern configured via service mesh (Istio, Linkerd) or application code, not a Dockerfile build pattern.

Full explanation →
120
MCQhard

A security team runs a multi-tenant cluster and wants a single, cluster-scoped policy that restricts which PersistentVolumeClaim StorageClasses each tenant namespace may use, rejecting any PVC that requests a non-approved StorageClass at admission time. They prefer a declarative, Kubernetes-native mechanism that requires no custom controller code. Which approach best meets this requirement?

A.A MutatingAdmissionWebhook that rewrites the PVC's storageClassName to an approved value before validation
B.A ResourceQuota in each tenant namespace that limits the number of PersistentVolumeClaims allowed
C.A ValidatingAdmissionPolicy with a CEL expression matching PersistentVolumeClaim objects, bound via a ValidatingAdmissionPolicyBinding with cluster scope
D.A ValidatingWebhookConfiguration pointing at a custom admission webhook service that inspects PVC StorageClass values
AnswerC

ValidatingAdmissionPolicy is a built-in, cluster-scoped admission mechanism that evaluates CEL expressions against incoming objects without requiring a webhook server. A cluster-scoped binding applies the rule to PVCs in all namespaces, and the CEL expression can inspect spec.storageClassName to reject non-approved values, satisfying the declarative, no-custom-controller requirement.

Why this answer

ValidatingAdmissionPolicy with a CEL expression lets administrators express admission rules directly in the cluster without deploying a webhook backend. Binding it at cluster scope applies the StorageClass restriction to PVCs across all tenant namespaces, and the expression can deny any claim whose spec.storageClassName falls outside the approved set, fully matching the declarative, native requirement.

Exam trap

The trap here is reaching for a ValidatingWebhookConfiguration out of habit, forgetting it requires an external webhook service while ValidatingAdmissionPolicy is built in.

Full explanation →
121
MCQhard

An external identity provider (OIDC) is integrated with your Kubernetes cluster. You want to restrict a group named 'contractors' so they can only view pods in the 'staging' namespace. Which configuration correctly maps this requirement?

A.A ClusterRole granting pod read access bound via a RoleBinding in the 'staging' namespace to the subject kind 'Group' with name 'contractors'.
B.A Namespace-scoped ServiceAccount configured with an OIDC JWT issuer URL.
C.A Role in the 'staging' namespace bound via a ClusterRoleBinding to the 'contractors' group.
D.An OIDC webhook configuration in the kube-apiserver specifying namespace boundaries.
AnswerA

A RoleBinding in the 'staging' namespace scopes the pod read permissions to that namespace only, satisfying the least-privilege constraint. Binding the ClusterRole to subject kind 'Group' named 'contractors' correctly maps the OIDC group claim, since Microsoft Entra ID supplies group membership as a group claim rather than individual user bindings.

Why this answer

A ClusterRole defines the permissions (read pods) at cluster scope, and a RoleBinding in the 'staging' namespace binds that ClusterRole to the 'contractors' Group, restricting the grant to only that namespace. This is the canonical pattern for granting cluster-defined permissions to a group within a single namespace.

Exam trap

KCSA often tests the RoleBinding-vs-ClusterRoleBinding distinction — candidates pick ClusterRoleBinding thinking 'ClusterRole needs ClusterRoleBinding', missing that a RoleBinding can reference a ClusterRole and scope it to one namespace.

How to eliminate wrong answers

Option B is wrong because a ServiceAccount is a workload identity, not a way to map an external OIDC group — OIDC groups are mapped via RBAC subjects of kind Group, not ServiceAccounts, and a ServiceAccount cannot carry an OIDC issuer URL. Option C is wrong because a ClusterRoleBinding grants permissions cluster-wide, so binding a staging Role via ClusterRoleBinding would not restrict the group to the staging namespace and is a privilege escalation risk. Option D is wrong because OIDC integration is configured via kube-apiserver flags (--oidc-issuer-url, --oidc-client-id, --oidc-groups-claim), not via a webhook configuration, and there is no 'namespace boundary' field in OIDC config.

Full explanation →
122
Multi-Selecteasy

Which THREE of the following are key components of the Kubernetes control plane? (Choose THREE)

Select 3 answers
A.kube-scheduler
B.container runtime (e.g., containerd)
C.kube-controller-manager
D.kube-proxy
E.kube-apiserver
AnswersA, C, E

kube-scheduler assigns unscheduled pods to nodes by evaluating resource requests, affinity rules and taints against available capacity. It runs as a control plane component alongside the API server and controller manager, satisfying the stem's requirement for a core control plane element rather than a worker-node agent such as kubelet.

Why this answer

The Kubernetes control plane is composed of the components that make global cluster decisions and expose the cluster API. Option E, kube-apiserver, is correct because it is the front end of the control plane, serving the REST API on port 6443 and acting as the central communication hub that all other components talk to. Option A, kube-scheduler, is correct because it watches for newly created Pods with no assigned node and selects a suitable node based on resource requirements, affinity, and taints/tolerations.

Option C, kube-controller-manager, is correct because it runs the core control loops (such as the node, replication, endpoints, and service account controllers) that reconcile desired state with observed state. Option B, the container runtime (e.g., containerd), is not a control plane component; it runs on every node (including workers) as part of the kubelet's container execution layer via the CRI. Option D, kube-proxy, is also not a control plane component; it runs on each node to implement Service networking rules via iptables or IPVS, making it a node-level networking component rather than part of the control plane.

Exam trap

KCSA often tests whether candidates can separate control-plane components from node components — the trap is selecting kube-proxy or the container runtime because they are essential to cluster operation, even though they run on worker nodes, not the control plane.

Full explanation →
123
MCQeasy

An auditor is evaluating the Kubernetes control plane attack surface. Which component exposes the primary interface for cluster management and must be protected with strong authentication and authorization?

A.CoreDNS
B.kube-proxy
C.kube-scheduler
D.kube-apiserver
AnswerD

The kube-apiserver is the sole entry point for control plane operations, serving the REST API that kubectl, controllers and nodes use. Every management request passes through it, so strong authentication and authorisation there protects the entire cluster.

Why this answer

The kube-apiserver is the central management interface for a Kubernetes cluster, exposing the REST API that all other components (kubectl, controllers, kubelets, schedulers) use to read and write cluster state. Because it is the single entry point for all control plane operations, it must be protected with strong authentication (client certs, OIDC, webhook tokens) and authorization (RBAC, ABAC, Node authorizer). Compromise of the API server effectively means full cluster compromise, making it the most critical attack surface to harden.

Exam trap

The trap is assuming any control plane component (scheduler, controller-manager) exposes the management API — only kube-apiserver does, and it is the component that must be hardened with authentication and RBAC.

How to eliminate wrong answers

Option A is wrong because CoreDNS is a cluster add-on that provides DNS resolution for services and pods; it does not expose a management API and is not the primary control plane interface. Option B is wrong because kube-proxy runs on each node to implement Service networking (iptables/IPVS rules) and does not expose a cluster management API. Option C is wrong because kube-scheduler is a control plane component that assigns pods to nodes based on resource and affinity rules, but it does not expose the primary management interface — it only watches the API server for unscheduled pods.

Full explanation →
124
MCQeasy

An application running in a pod needs to securely consume a database password without storing it in plaintext within the container image or deployment manifest. Which native Kubernetes resource is best suited for storing this sensitive key-value data?

A.PersistentVolumeClaim
B.ResourceQuota
C.Secret
D.ConfigMap
AnswerC

Secrets store sensitive key-value data separately from pod specifications and container images, so the database password never appears in plaintext in the deployment manifest. Pods consume it via environment variables or mounted volumes, satisfying the requirement to avoid embedding credentials in the image.

Why this answer

A Kubernetes Secret is the native resource designed to hold sensitive key-value data such as passwords, tokens, and TLS keys, keeping them out of container images and manifests. Pods consume Secrets via environment variables or mounted volumes, and the API server stores them base64-encoded (with optional encryption at rest via EncryptionConfiguration). ConfigMaps are for non-sensitive configuration, so a database password belongs in a Secret.

Exam trap

KCSA often tests the misconception that base64 encoding in a Secret equals encryption, luring candidates toward ConfigMap or assuming Secrets are automatically encrypted at rest.

How to eliminate wrong answers

Option A is wrong because a PersistentVolumeClaim only requests storage from a PersistentVolume and has nothing to do with storing key-value secrets. Option B is wrong because a ResourceQuota enforces namespace-level limits on resource consumption (CPU, memory, object counts), not secret storage. Option D is wrong because a ConfigMap is intended for non-confidential configuration data and is stored in plaintext without the sensitivity handling that Secrets provide.

Full explanation →
125
Multi-Selectmedium

Which TWO of the following actions are considered best practices for securing Kubernetes Secrets? (Choose TWO)

Select 2 answers
A.Store database passwords in plaintext ConfigMaps for easier application ingestion.
B.Enable encryption at rest for Secret resources in etcd.
C.Rely on base64 encoding as the primary encryption mechanism for sensitive data.
D.Strictly limit RBAC permissions so that only necessary users and service accounts can read Secrets.
E.Mount Secrets as writable volumes so applications can update their own credentials.
AnswersB, D

Encrypting Secrets at rest protects the etcd datastore, where Kubernetes persists Secret objects unencrypted by default. Enabling an encryption provider configuration ensures that anyone reading etcd's underlying files or backups cannot recover plaintext credentials, directly satisfying the best-practise requirement to secure Secret data beyond RBAC and API-level controls.

Why this answer

Option B is correct because enabling encryption at rest for Secret resources protects the data stored in etcd, so even if an attacker gains access to the etcd data files or backups, the Secret contents are encrypted rather than exposed as plaintext. Option D is correct because Kubernetes Secrets are only as secure as the RBAC policy around them; strictly limiting who and which service accounts can read Secrets reduces the risk of credential theft and follows least-privilege best practice. Option A is not a best practice because ConfigMaps are not designed for sensitive data and store values in plaintext, making database passwords easily readable.

Option C is incorrect because base64 is merely an encoding, not encryption, and provides no confidentiality. Option E is not recommended because mounting Secrets as writable volumes can allow applications or attackers to modify credentials and increases the attack surface; Secrets should generally be mounted read-only unless there is a specific need.

Exam trap

KCSA often tests the misconception that base64 encoding equals encryption — candidates pick the base64 answer or the ConfigMap answer, missing that only encryption at rest plus RBAC least privilege constitute real Secret security.

Full explanation →
126
MCQhard

A platform engineer is hardening a container runtime setup on worker nodes. They want to ensure that containers cannot make unauthorized changes to network configurations or mount host filesystems. Which capability must be explicitly dropped from the default container capabilities set?

A.CAP_CHOWN
B.CAP_NET_BIND_SERVICE
C.CAP_SYS_ADMIN
D.CAP_DAC_OVERRIDE
AnswerC

CAP_SYS_ADMIN is the broadest Linux capability, granting mount, namespace and network configuration privileges. Dropping it directly satisfies the stem's constraint that containers must not alter network settings or mount host filesystems, since those operations require this capability rather than narrower ones like CAP_NET_ADMIN alone.

Why this answer

CAP_SYS_ADMIN is the most powerful Linux capability, granting broad administrative privileges including mounting filesystems, modifying network configuration, and accessing kernel features. Dropping it prevents containers from performing privileged operations like mounting host filesystems or reconfiguring network interfaces, which are common container-escape and node-compromise vectors.

Exam trap

KCSA often tests whether candidates know that CAP_SYS_ADMIN is the 'super-capability' covering mounts and network admin, luring them toward narrower capabilities like CAP_CHOWN or CAP_NET_BIND_SERVICE that sound relevant but lack the required scope.

How to eliminate wrong answers

Option A is wrong because CAP_CHOWN only permits changing file ownership (chown) — it does not enable network reconfiguration or filesystem mounting. Option B is wrong because CAP_NET_BIND_SERVICE merely allows binding to privileged ports below 1024, a narrow networking privilege unrelated to host mounts or network stack changes. Option D is wrong because CAP_DAC_OVERRIDE bypasses file read/write/execute permission checks — dangerous for file access but not the capability that governs mount and network namespace operations.

Full explanation →
127
MCQmedium

A security auditor is evaluating a cloud-native deployment. The team states they practice 'shift-left' security. Which of the 4Cs does this practice primarily target?

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

Shift-left security moves testing, scanning and secure coding earlier into development, so it primarily targets the Code layer of the 4Cs. This addresses vulnerabilities at their origin rather than relying on runtime or host controls later in the pipeline.

Why this answer

'Shift-left' security means moving security practices earlier in the software development lifecycle — into design, coding, and CI/CD — which maps to the 'Code' layer of the 4Cs (Cloud, Cluster, Container, Code). This includes SAST, dependency scanning, secrets detection, and secure coding standards applied before deployment.

Exam trap

KCSA often tests whether candidates map 'shift-left' to the wrong C — the trap is picking Container or Cluster because those feel security-related, when shift-left is fundamentally about code-time practices.

How to eliminate wrong answers

Option A is wrong because the Container layer covers image scanning, minimal base images, and runtime container security — important, but shift-left primarily targets code-time practices. Option B is wrong because the Cluster layer covers Kubernetes RBAC, network policies, and admission controllers — these are deployment/runtime controls, not shift-left. Option D is wrong because the Cloud layer covers IAM, network segmentation, and cloud provider security — infrastructure-level, not code-level shift-left.

Full explanation →
128
MCQhard

A security engineer is configuring a seccomp profile for a critical application pod running in a hardened Kubernetes cluster to restrict system calls. The pod requires access to the networking stack but must block module loading. Where must this custom JSON seccomp profile be placed on a worker node running containerd so that it can be referenced via the pod security spec?

A./var/log/containers/
B./etc/kubernetes/manifests/
C./var/lib/kubelet/seccomp/
D./etc/containerd/certs.d/
AnswerC

Placing the profile under /var/lib/kubelet/seccomp/ satisfies the kubelet's default seccomp root path, which is where containerd resolves local profiles referenced by the pod's securityContext. The pod spec then cites it relatively, such as localhost/profiles/block-modules.json, blocking module loading while permitting networking syscalls.

Why this answer

Custom seccomp profiles referenced by kubelet must be placed in the kubelet's seccomp root directory, which defaults to /var/lib/kubelet/seccomp/ on the worker node. The pod spec then references the profile via securityContext.seccompProfile with type Localhost and a relative path under that directory. This is the documented location for local seccomp profiles in Kubernetes.

Exam trap

KCSA often tests the confusion between various Kubernetes node directories — candidates must know that seccomp profiles live under /var/lib/kubelet/seccomp/, not in manifest, log, or containerd config directories.

How to eliminate wrong answers

Option A is wrong because /var/log/containers/ holds container log symlinks managed by the kubelet/container runtime, not seccomp profiles. Option B is wrong because /etc/kubernetes/manifests/ is where static pod manifests are placed for the kubelet to run control plane components — it has nothing to do with seccomp. Option D is wrong because /etc/containerd/certs.d/ is used for containerd registry TLS certificate configuration, not seccomp profiles.

Full explanation →
129
MCQhard

An auditor is evaluating the security posture of an on-premises Kubernetes cluster. The team notices that the etcd data directory is stored without encryption at rest. What is the primary threat this exposes the cluster to?

A.Direct exposure of all Kubernetes Secrets in plain text to anyone with read access to etcd storage
B.Inability of worker nodes to perform TLS handshakes with the API server
C.Immediate failure of HorizontalPodAutoscaler metric polling loops
D.Automatic elevation of all ServiceAccounts to cluster-admin privileges
AnswerA

etcd stores Secrets unencrypted by default, so anyone with read access to its data directory or backups can read every Secret in plain text. This directly exposes credentials and tokens cluster-wide, which is the primary threat of missing encryption at rest.

Why this answer

Without encryption at rest, etcd stores all Kubernetes objects—including Secrets—in plaintext on disk. Anyone with read access to the etcd data directory (e.g., via filesystem access, stolen disk, or backup) can directly read sensitive data like service account tokens, database passwords, and TLS keys. This is the primary threat because etcd is the single source of truth for cluster state, and encryption at rest is a defense-in-depth measure specifically designed to protect this data if the storage medium is compromised.

Exam trap

KCSA often tests the misconception that etcd encryption at rest is about network security or performance, when it is actually about protecting data confidentiality on disk; candidates may confuse it with TLS or RBAC.

How to eliminate wrong answers

Option B is wrong because worker node TLS handshakes with the API server rely on certificates and network encryption, not on etcd encryption at rest; etcd encryption does not affect TLS negotiation. Option C is wrong because HorizontalPodAutoscaler metric polling depends on the metrics API and controller manager, not on etcd encryption; lack of encryption does not cause immediate failure of HPA loops. Option D is wrong because ServiceAccount privileges are determined by RBAC and admission controllers, not by etcd encryption; encryption at rest does not automatically elevate permissions.

Full explanation →
130
MCQeasy

Which protocol and default secure port does the kubelet use to listen for incoming authenticated requests from the API server and metrics collectors?

A.HTTPS on port 10250
B.HTTPS on port 6443
C.TCP on port 2379
D.HTTP on port 10255
AnswerA

The kubelet serves its authenticated HTTPS endpoint on port 10250, used by the API server for logs, exec and metrics, and by metrics collectors. HTTPS on 10250 satisfies the stem's requirement for a secure, authenticated protocol and default port.

Why this answer

The kubelet listens on HTTPS port 10250 by default for authenticated requests from the API server (e.g., kubectl logs, exec) and from metrics collectors like the metrics-server. This port requires authentication and authorization (via the kubelet's --authorization-mode and client CA), and it is the standard secure endpoint for kubelet API access. Port 10255 is the read-only, unauthenticated HTTP port that is disabled by default in modern Kubernetes due to security concerns.

Exam trap

KCSA often tests whether candidates confuse the API server port (6443) with the kubelet port (10250) or the deprecated read-only port (10255) — the trap is picking 6443 because it is the most familiar Kubernetes port, when the question specifically asks about the kubelet.

How to eliminate wrong answers

Option B is wrong because port 6443 is the default secure port for the Kubernetes API server (kube-apiserver), not the kubelet — confusing the two is a common mistake. Option C is wrong because port 2379 is the default client port for etcd, the cluster datastore, not the kubelet. Option D is wrong because port 10255 is the kubelet's read-only, unauthenticated HTTP port, which is deprecated and disabled by default in current Kubernetes versions due to the security risk of exposing node and pod information without authentication.

Full explanation →
131
MCQmedium

You are configuring an Ingress object with TLS termination. The TLS certificate and private key are stored in a Kubernetes Secret. Which specific secret type must be used to ensure the ingress controller recognizes and validates the TLS credentials correctly?

A.kubernetes.io/tls
B.kubernetes.io/service-account-token
C.Opaque
D.kubernetes.io/dockerconfigjson
AnswerA

`kubernetes.io/tls` is the dedicated Secret type whose `tls.crt` and `tls.key` keys ingress controllers require for TLS termination. Generic `Opaque` secrets store the same data but lack the type marker, so the controller cannot recognise or validate the credentials, breaking the Ingress TLS configuration.

Why this answer

The kubernetes.io/tls secret type is specifically designed to hold a TLS certificate and its private key, with required keys 'tls.crt' and 'tls.key'. Ingress controllers look for this type to correctly load and validate the certificate for TLS termination.

Exam trap

KCSA often tests the assumption that any secret with the right keys works, but the exam expects knowledge that the kubernetes.io/tls type is required for ingress controllers to properly recognize and validate TLS credentials.

How to eliminate wrong answers

Option B is wrong because kubernetes.io/service-account-token is used to store a token for a service account, not TLS credentials. Option C is wrong because Opaque is a generic secret type for arbitrary data and does not guarantee the presence of the required TLS keys, so the ingress controller may not recognize it. Option D is wrong because kubernetes.io/dockerconfigjson is for storing Docker registry credentials, not TLS certificates.

Full explanation →
132
MCQhard

When configuring a MutatingWebhookConfiguration, you notice that mutating webhooks are executed before validating webhooks. Why is this execution order critical for security and consistency?

A.It ensures that validating webhooks evaluate the final, mutated state of the object rather than the original input.
B.It prevents mutating webhooks from timing out while waiting for validation checks.
C.Mutating webhooks require encryption keys generated during the validation phase.
D.It allows validating webhooks to override any changes made by mutating webhooks if security violations occur.
AnswerA

Mutating webhooks run first so they can alter the object before admission. Validating webhooks then assess that mutated result, ensuring policies are enforced against the exact configuration that will persist, rather than a pre-mutation version that could bypass security checks.

Why this answer

Mutating webhooks run before validating webhooks so that validating webhooks evaluate the final, mutated version of the object. This ensures that validation is performed against the actual state that will be persisted, preventing inconsistencies and security gaps where a mutation could bypass validation.

Exam trap

KCSA often tests the admission control order and its security implications, and candidates may incorrectly think validating webhooks can override mutations or that order is for performance.

How to eliminate wrong answers

Option B is wrong because the order is not about preventing timeouts; it is about ensuring validation sees the final object. Option C is wrong because mutating webhooks do not require encryption keys generated during validation; encryption is unrelated to webhook ordering. Option D is wrong because validating webhooks cannot override changes made by mutating webhooks; they can only allow or deny the final object.

Full explanation →
133
MCQhard

Your cluster uses the Pod Security admission controller with the 'restricted' profile enforced. A legacy application pod fails to start because it requires running as root (runAsNonRoot: false). How should you handle this securely without disabling the standard?

A.Disable the Pod Security admission controller entirely across the cluster.
B.Configure the Pod Security admission configuration file on the control plane to exempt the specific ServiceAccount or namespace from the restricted check.
C.Set the namespace enforce level to 'privileged' permanently.
D.Mount the host socket inside the pod to bypass user namespace restrictions.
AnswerB

Exempting the specific ServiceAccount or namespace via the admission configuration file lets the legacy root-requiring pod run while the restricted profile stays enforced cluster-wide. This is the documented, least-privilege exception mechanism, avoiding the insecure option of disabling the standard entirely.

Why this answer

The Pod Security admission configuration file (passed to kube-apiserver via --admission-control-config-file) supports per-namespace and per-ServiceAccount exemptions from a given Pod Security level. Exempting the specific ServiceAccount or namespace that runs the legacy root-requiring workload lets that pod start while the 'restricted' profile remains enforced everywhere else. This is the least-privilege, targeted approach that preserves cluster-wide security posture.

Exam trap

The trap here is assuming the only ways to handle a restricted-profile failure are to disable the controller or downgrade the whole namespace, when the exam expects knowledge of the granular exemptions stanza in the Pod Security admission configuration file.

How to eliminate wrong answers

Option A is wrong because disabling the Pod Security admission controller removes enforcement cluster-wide, eliminating a core defense-in-depth control and exposing all workloads to privilege escalation. Option C is wrong because setting the namespace enforce level to 'privileged' permanently disables all Pod Security restrictions for that namespace, not just for the one legacy pod, which is far broader than necessary. Option D is wrong because mounting the host socket (e.g., /var/run/docker.sock or containerd socket) is a severe container escape vector that grants effective host root — it bypasses security rather than handling the exception securely.

Full explanation →
134
MCQmedium

A platform team runs a shared Kubernetes cluster where each tenant namespace contains a ServiceAccount named 'builder'. CI pipelines in the 'ci' namespace authenticate as 'ci:builder' and need to create Deployments only in that same namespace. A security engineer must write a RoleBinding that grants the 'edit' ClusterRole to this identity without granting rights in any other namespace. Which subject entry should the RoleBinding contain?

A.kind: ServiceAccount, name: builder, namespace: default
B.kind: ServiceAccount, name: builder, namespace: ci
C.kind: User, name: ci:builder
D.kind: Group, name: system:serviceaccounts:ci
AnswerB

A RoleBinding lives in a namespace and can reference a ServiceAccount from that same namespace by setting kind to ServiceAccount along with its name and namespace. Binding the built-in edit ClusterRole here grants the CI identity rights only within the 'ci' namespace, which is exactly the least-privilege scope the security engineer needs.

Why this answer

A namespaced RoleBinding grants permissions only inside its own namespace, and a ServiceAccount subject is identified by its name plus its namespace. Referencing 'builder' in the 'ci' namespace ties the edit ClusterRole to precisely the CI identity that needs to create Deployments there, while leaving every other namespace untouched.

Exam trap

The trap here is assuming the colon-delimited authenticated username 'ci:builder' should be written as a User subject instead of referencing the ServiceAccount object itself.

Full explanation →
135
MCQhard

You are reviewing admission webhook configurations and notice that timeoutSeconds is set to 3 seconds for a critical validation webhook. If the webhook server takes 4 seconds to respond, what does the API server do when failurePolicy is 'Ignore'?

A.It quarantines the pod in a Pending state.
B.It rejects the API request immediately.
C.It retries the webhook request indefinitely until it responds.
D.It allows the API request to proceed as if the webhook succeeded.
AnswerD

With failurePolicy set to Ignore, a webhook call exceeding timeoutSeconds is treated as non-blocking, so the API server admits the request without the webhook's verdict. The 4-second response arrives too late to affect the outcome.

Why this answer

With failurePolicy set to Ignore, when the webhook exceeds timeoutSeconds (3s) and takes 4s to respond, the API server abandons the call and admits the request as if the webhook had allowed it. Ignore means failures — including timeouts — are non-blocking. The request proceeds without the webhook's validation result.

Exam trap

The trap is assuming a timeout always blocks the request — candidates forget that failurePolicy governs the outcome, and Ignore means timeouts and errors are swallowed, letting the request through.

How to eliminate wrong answers

Option A is wrong because Kubernetes has no quarantine mechanism that parks pods in Pending due to webhook timeouts; Pending reflects scheduling or image pull issues, not admission outcomes. Option B is wrong because immediate rejection describes failurePolicy: Fail, not Ignore. Option C is wrong because the API server does not retry webhook calls indefinitely; it makes a single call bounded by timeoutSeconds (default 10s, max 30s) and then applies the failurePolicy.

Full explanation →
136
MCQeasy

A security engineer wants to apply Pod Security Standards globally across an entire namespace using the modern built-in admission mechanism. Which approach should be used?

A.Create a MutatingWebhookConfiguration that injects security contexts into every pod spec.
B.Apply labels such as 'pod-security.kubernetes.io/enforce=restricted' to the namespace metadata.
C.Modify the kubelet configuration file on every worker node to enable restricted mode.
D.Deploy a custom PodSecurityPolicy object targeting the namespace selector.
AnswerB

Pod Security Admission is built into the API server and enforces Pod Security Standards per namespace via labels such as pod-security.kubernetes.io/enforce. Labelling namespace metadata applies the restricted profile globally across that namespace, satisfying the stem's modern built-in mechanism requirement.

Why this answer

The correct approach is to apply labels to the namespace metadata, such as 'pod-security.kubernetes.io/enforce=restricted'. This is the built-in Pod Security Admission (PSA) mechanism introduced in Kubernetes 1.23, which enforces Pod Security Standards (PSS) at the namespace level. By labeling the namespace, the PSA controller automatically validates pod creation against the specified policy (privileged, baseline, or restricted) without needing external webhooks or node-level changes.

This method is the modern, native way to apply PSS globally across a namespace.

Exam trap

KCSA often tests the confusion between deprecated PodSecurityPolicy and the modern Pod Security Admission, leading candidates to pick PSP-related answers even though PSP is removed in recent Kubernetes versions.

How to eliminate wrong answers

Option A is wrong because a MutatingWebhookConfiguration is used to mutate pod specs, not to enforce Pod Security Standards; it would require custom logic and is not the built-in admission mechanism. Option C is wrong because kubelet configuration does not control Pod Security Standards; kubelet settings affect node-level behavior, not namespace-wide pod admission policies. Option D is wrong because PodSecurityPolicy (PSP) is a deprecated and removed feature (as of Kubernetes 1.25) and is not the modern built-in mechanism; it also requires enabling the PSP admission controller and does not use namespace labels for enforcement.

Full explanation →
137
Multi-Selecteasy

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

Select 2 answers
A.Disabling all automated security tooling to speed up commits
B.Scanning infrastructure-as-code (IaC) templates for misconfigurations before deployment
C.Waiting until a production breach occurs to audit logs
D.Integrating vulnerability scanning directly into the CI/CD pipeline
E.Relying entirely on manual code reviews post-release
AnswersB, D

Scanning IaC templates pre-deployment catches misconfigurations while they remain cheap, editable code rather than live cloud resources. This satisfies Shift-Left's core tenet of moving security controls into earlier development phases, before artefacts reach production, where remediation demands change requests, redeployment and potential outage windows.

Why this answer

Option B is correct because Shift-Left security means identifying misconfigurations in infrastructure-as-code (IaC) templates such as Terraform, CloudFormation, or Kubernetes manifests during development, before any resources are provisioned, so issues are caught early when they are cheapest and safest to fix. Option D is correct because embedding vulnerability scanning (for example SAST, SCA, or container image scanning) directly into the CI/CD pipeline enforces automated security gates on every commit or build, which is the operational core of shifting security left into the development lifecycle. Option A is wrong because disabling automated security tooling removes the very guardrails Shift-Left depends on and increases risk rather than reducing it.

Option C is wrong because auditing only after a production breach is a reactive, right-side-of-development approach, the opposite of Shift-Left. Option E is wrong because relying solely on manual post-release code reviews is late, non-automated, and does not prevent defects from reaching production.

Exam trap

KCSA often tests the misconception that Shift-Left means adding more manual review steps or post-release audits, when it actually means automating security checks earlier in the pipeline.

Full explanation →
138
MCQhard

An enterprise is deploying a zero-trust architecture across their Kubernetes environments. They mandate that all container images must be signed using Cosign and verified at admission time using Kyverno. This technical control directly hardens which of the 4Cs layers?

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

Cosign signing and Kyverno admission verification operate on the image artefact itself, validating its signature and provenance before it runs. This hardens the Container layer of the 4Cs model, which covers image integrity and supply chain trust.

Why this answer

Cosign image signing combined with Kyverno admission-time verification is a container-layer control because it governs the integrity and provenance of the container image artifact itself before it is admitted to run. The Container layer of the 4Cs (Cloud, Cluster, Container, Code) covers image contents, image provenance, and runtime configuration of the container. Signing and verifying images ensures only trusted, unmodified images execute, which is a direct hardening of that layer.

Exam trap

KCSA often tests the boundary between the Container layer (image artifact integrity) and the Cluster layer (admission control enforcement), causing candidates to pick Cluster because Kyverno is a cluster component — but the control hardens the image artifact, which is Container layer.

How to eliminate wrong answers

Option A is wrong because the Code layer addresses application source code, dependencies, and CI/CD pipeline security (e.g., SAST, SCA, secret scanning), not the signed container artifact verified at admission. Option B is wrong because the Cloud layer covers the underlying cloud provider infrastructure, IAM, network, and API security, not image signing. Option D is wrong because the Cluster layer covers control plane components, RBAC, admission controllers configuration, network policies, and node hardening — Kyverno is the enforcement mechanism, but the artifact being protected (the signed image) belongs to the Container layer.

Full explanation →
139
Multi-Selectmedium

Which THREE of the following are characteristics of Zero Trust security models in cloud-native environments? (Choose THREE)

Select 3 answers
A.Relying entirely on network firewalls at the cloud perimeter
B.Explicitly verifying identity and context for every access request
C.Assuming breach and implementing micro-segmentation
D.Applying the principle of least privilege access
E.Implicit trust for all traffic originating inside the internal corporate network
AnswersB, C, D

Zero Trust replaces implicit network trust with per-request authentication and authorisation. Every access request must be explicitly verified using identity and contextual signals such as device posture, location and workload identity, satisfying the model's requirement that no request is trusted by default.

Why this answer

Option B is correct because Zero Trust requires explicit verification of identity and context (user, device, location, workload) for every access request rather than granting access based on network location. Option C is correct because Zero Trust operates on an 'assume breach' mindset, using micro-segmentation to limit lateral movement between workloads and services. Option D is correct because least privilege access is a core Zero Trust principle, granting only the minimum permissions needed for a specific task and enforcing just-in-time and just-enough-access.

Option A is incorrect because relying solely on perimeter firewalls reflects a traditional castle-and-moat model, which Zero Trust explicitly rejects in favor of identity-centric controls. Option E is incorrect because implicit trust for internal traffic is the opposite of Zero Trust, which treats all networks as untrusted and verifies every request regardless of origin.

Exam trap

KCSA often tests whether candidates recognize that 'internal network = trusted' is the anti-pattern Zero Trust was created to eliminate, so any option implying implicit internal trust is wrong.

Full explanation →
140
Multi-Selecthard

Which TWO components are involved in configuring and processing admission webhooks in a Kubernetes cluster?

Select 2 answers
A.kube-apiserver
B.ValidatingWebhookConfiguration
C.kube-proxy
D.kubelet
E.etcd daemon
AnswersA, B

The kube-apiserver hosts the admission chain, invoking mutating then validating webhooks during API request processing. It satisfies the stem's requirement for a component that processes webhooks, since it calls registered webhook endpoints and enforces their decisions before persisting objects to etcd.

Why this answer

The kube-apiserver (A) is the component that actually invokes admission webhooks: when a request reaches the admission chain, the API server sends an AdmissionReview request over HTTPS to each matching webhook and processes the returned AdmissionReview response to allow or deny the object. ValidatingWebhookConfiguration (B) is the cluster-scoped API resource that registers validating webhooks with the API server, specifying the webhook's clientConfig (URL or service reference), the rules that select which resources/operations trigger it, and failurePolicy, so it is essential to configuring admission webhooks. kube-proxy (C) only programs Service/Endpoint networking rules (iptables/IPVS) on nodes and plays no role in the admission chain. kubelet (D) runs pods on a node and does not evaluate admission webhooks. The etcd daemon (E) merely stores cluster state, including webhook configuration objects, but does not configure or process admission requests.

Exam trap

KCSA often tests the confusion between node-level components (kubelet, kube-proxy) and control-plane admission machinery, tempting candidates to pick kubelet as a webhook processor.

Full explanation →
141
MCQeasy

Which file on a Kubernetes control plane node contains the startup arguments and flags for the statically hosted API server?

A./etc/systemd/system/kube-apiserver.service
B./etc/kubernetes/manifests/kube-apiserver.yaml
C./etc/default/kube-apiserver
D./var/lib/kubelet/config.yaml
AnswerB

Static pods are defined by manifest files in /etc/kubernetes/manifests, which the kubelet watches and reconciles. The kube-apiserver.yaml manifest there holds the API server's startup arguments and flags, making it the authoritative source for that component's configuration.

Why this answer

On kubeadm-provisioned control plane nodes, the API server runs as a static Pod, and its manifest — including all command-line flags such as --advertise-address, --etcd-servers, and --authorization-mode — lives at /etc/kubernetes/manifests/kube-apiserver.yaml. The kubelet watches this directory and starts/restarts the static Pod whenever the file changes, so editing this YAML is how administrators modify API server startup arguments.

Exam trap

The trap is assuming the API server is a systemd service (like kubelet) and therefore choosing a .service file, when in kubeadm clusters it is a static Pod defined in /etc/kubernetes/manifests/.

How to eliminate wrong answers

Option A is wrong because /etc/systemd/system/kube-apiserver.service is not the standard location for the API server unit in kubeadm clusters — the API server is a static Pod, not a systemd-managed service (though kubelet itself is a systemd service). Option C is wrong because /etc/default/kube-apiserver is not a standard Kubernetes path; /etc/default is used for environment files of some systemd services, not for the API server's flags. Option D is wrong because /var/lib/kubelet/config.yaml is the kubelet's own configuration file (KubeletConfiguration), which governs kubelet behavior, not API server startup flags.

Full explanation →
142
MCQeasy

What is the primary risk associated with running containers as the `root` user (`runAsUser: 0` or omitting the user directive)?

A.If a container escape vulnerability occurs, the attacker immediately obtains root privileges on the underlying host.
B.It prevents the kubelet from restarting the container upon failure.
C.It disables the container runtime engine's ability to pull images from private registries.
D.It forces the CNI plugin to drop network packets destined for external IPs.
AnswerA

Running as root means a container escape grants immediate host root privileges, because the container process's UID maps directly to host root unless user namespaces or a non-root runAsUser are configured. This satisfies the stem's constraint identifying the primary risk of runAsUser: 0.

Why this answer

Running a container as root (UID 0) means that if an attacker exploits a container escape vulnerability, they gain root privileges on the host node because the container process runs as root in the host's user namespace (unless user namespaces are enabled). This violates the principle of least privilege and significantly increases the blast radius of a compromise. The other options are unrelated to user ID configuration.

Exam trap

KCSA often tests the misconception that container isolation alone prevents host compromise, but running as root inside the container can lead to immediate host root access upon escape.

How to eliminate wrong answers

Option B is wrong because container restart behavior is controlled by the pod's restartPolicy and the kubelet's lifecycle management, not by the user ID the container runs as. Option C is wrong because pulling images from private registries depends on imagePullSecrets and registry authentication, not on the container's runAsUser setting. Option D is wrong because CNI plugins handle network traffic based on network policies and routing rules, not on the user ID inside the container.

Full explanation →
143
MCQhard

An organization mandates that all traffic entering the service mesh must be decrypted at the ingress gateway, inspected by a Web Application Firewall (WAF), and then re-encrypted using mTLS before reaching backend pods. What is this architectural pattern called within service mesh security?

A.HTTP plaintext tunneling
B.Pod security standard restriction
C.DNS-based load balancing
D.TLS re-encryption (or edge termination with backend mTLS)
AnswerD

The ingress gateway terminates inbound TLS, passes plaintext to the WAF for inspection, then re-encrypts with mTLS to backend pods. This decrypt-inspect-re-encrypt flow is TLS re-encryption, satisfying the mandate that traffic be inspected and re-encrypted before reaching pods.

Why this answer

TLS re-encryption (also called edge termination with backend mTLS) is the pattern where the ingress gateway terminates external TLS, passes traffic to a WAF or inspection layer in plaintext, then re-encrypts with mTLS before forwarding to backend pods. This preserves end-to-end encryption inside the mesh while allowing inspection at the edge.

Exam trap

KCSA often tests the distinction between TLS termination, passthrough, and re-encryption — candidates may pick 'passthrough' or 'termination' without recognizing the re-encryption requirement.

How to eliminate wrong answers

Option A is wrong because HTTP plaintext tunneling describes unencrypted traffic forwarding, which contradicts the requirement for mTLS to backends and would violate security mandates. Option B is wrong because Pod Security Standards govern pod privilege and runtime settings, not traffic encryption or WAF inspection flows. Option C is wrong because DNS-based load balancing is a traffic distribution mechanism, not an encryption/inspection architecture.

Full explanation →
144
MCQmedium

An application pod requires read access to secrets in the 'production' namespace. You need to bind a pre-existing ClusterRole named 'secret-reader' to a service account named 'app-sa' in that namespace. Which RBAC resource accomplishes this?

A.ClusterRoleBinding referencing the Role 'secret-reader'
B.NamespaceRoleBinding referencing the ClusterRole
C.RoleBinding referencing the ClusterRole 'secret-reader'
D.ServiceAccountBinding referencing the ClusterRole
AnswerC

A RoleBinding grants permissions within a single namespace, so binding the existing ClusterRole 'secret-reader' to 'app-sa' in 'production' satisfies the requirement for namespace-scoped secret read access. Unlike a ClusterRoleBinding, which would grant cluster-wide access, this confines the permissions correctly.

Why this answer

A RoleBinding grants the permissions defined in a referenced Role or ClusterRole to subjects within a specific namespace. Binding the pre-existing ClusterRole 'secret-reader' via a RoleBinding in the 'production' namespace grants those permissions only in that namespace to the 'app-sa' service account. This is the standard pattern for reusing a ClusterRole's permission set in a single namespace.

Exam trap

KCSA often tests the subtle rule that a RoleBinding can reference a ClusterRole but a ClusterRoleBinding cannot reference a Role, and candidates frequently confuse the two binding types or invent non-existent kinds.

How to eliminate wrong answers

Option A is wrong because a ClusterRoleBinding grants permissions cluster-wide and cannot reference a namespaced Role — it only references ClusterRoles, and it would violate the namespace-scoped requirement. Option B is wrong because 'NamespaceRoleBinding' is not a real Kubernetes resource kind; the correct kinds are RoleBinding and ClusterRoleBinding. Option D is wrong because 'ServiceAccountBinding' is not a Kubernetes resource kind — service accounts are bound via RoleBinding or ClusterRoleBinding.

Full explanation →
145
MCQhard

You are configuring a runtime security agent that uses Falco to detect unexpected shell execution inside containers. The security rule triggers when a process spawns a shell binary (e.g., bash or sh) inside a container namespace. Which underlying Linux kernel mechanism allows Falco to detect this event with minimal overhead?

A.Periodic polling of container logs using kubectl logs
B.eBPF system call tracing and kernel event capture
C.Analyzing CoreDNS lookup history
D.Inspecting etcd database keys every second
AnswerB

eBPF attaches programmes to kernel tracepoints and syscall hooks, capturing execve calls as they occur in the container namespace. This satisfies the minimal-overhead constraint because eBPF runs in-kernel without context-switching to userspace per event, unlike auditd or ptrace-based monitoring, letting Falco detect shell spawns efficiently.

Why this answer

Falco uses eBPF system call tracing and kernel event capture (B) to detect process executions like shell spawning with minimal overhead. eBPF allows Falco to hook into kernel tracepoints and syscalls without modifying the kernel or using heavy agents.

Exam trap

The trap is confusing log-based or API-based monitoring with kernel-level event capture. Candidates might think that kubectl logs or etcd inspection can detect runtime events, but only eBPF (or similar kernel mechanisms) provides the necessary real-time, low-level visibility.

How to eliminate wrong answers

Option A is wrong because periodic polling of container logs using kubectl logs is reactive, high-latency, and cannot reliably detect process execution events; it also misses events if logs are rotated. Option C is wrong because analyzing CoreDNS lookup history only provides DNS query data, not process execution. Option D is wrong because inspecting etcd database keys every second is inefficient, unrelated to runtime process monitoring, and would not detect shell execution inside containers.

Full explanation →
146
MCQmedium

A CI/CD pipeline service account needs permission to create Deployments and Services across multiple namespaces, but should not have cluster-admin privileges. What is the most secure way to grant these permissions?

A.Define a ClusterRole with the required verbs and resources, then create a RoleBinding for that ClusterRole in each target namespace.
B.Place the service account in the kube-system namespace.
C.Grant the service account permissions at the node level using kubeconfig overrides.
D.Create a ClusterRoleBinding linking the default cluster-admin ClusterRole to the service account.
AnswerA

A ClusterRole defines the required verbs and resources once, while RoleBindings scope that permission to each target namespace. This satisfies the least-privilege constraint: the service account gains Deployment and Service creation only where bound, never cluster-wide, unlike a ClusterRoleBinding which would grant access across all namespaces.

Why this answer

A ClusterRole defines permissions cluster-wide but does not grant them until bound. By creating a RoleBinding in each target namespace that references the ClusterRole, the service account receives only the specified verbs (create) on the specified resources (Deployments, Services) within those namespaces. This follows the principle of least privilege and avoids cluster-admin rights.

Exam trap

KCSA often tests the misconception that a ClusterRole always grants cluster-wide permissions; in fact, it only defines permissions, and a RoleBinding can restrict its scope to a single namespace.

How to eliminate wrong answers

Option B is wrong because placing the service account in kube-system does not grant any permissions; namespace placement alone has no RBAC effect. Option C is wrong because kubeconfig overrides are a client-side mechanism and do not grant server-side RBAC permissions; node-level access is unrelated to Kubernetes API authorization. Option D is wrong because binding cluster-admin grants full cluster-wide privileges, violating the requirement to avoid cluster-admin.

Full explanation →
147
Multi-Selecthard

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

Select 3 answers
A.Using sandboxed container runtimes (such as Kata Containers or gVisor) for strong isolation
B.Running all containers in privileged mode
C.Mounting host /proc and /sys directories in read-write mode
D.Applying restrictive Seccomp profiles to block sensitive system calls
E.Dropping dangerous capabilities like CAP_SYS_ADMIN, CAP_NET_RAW, and CAP_SYS_PTRACE
AnswersA, D, E

Sandboxed runtimes such as Kata Containers and gVisor interpose a lightweight VM or user-space kernel between the container and the host kernel, so a container breakout exploit reaches only the sandbox boundary, not the shared host kernel.

Why this answer

Option A is correct because sandboxed runtimes such as Kata Containers and gVisor insert a lightweight VM or user-space kernel boundary between the container and the host kernel, so a kernel exploit inside the container does not directly compromise the host. Option D is correct because restrictive Seccomp profiles filter the syscall table and block sensitive calls (for example, ptrace, mount, or unshare) that container breakout exploits rely on to escape isolation. Option E is correct because dropping dangerous Linux capabilities such as CAP_SYS_ADMIN, CAP_NET_RAW, and CAP_SYS_PTRACE removes the privileges needed to mount filesystems, craft raw packets, or inject into host processes, which are common breakout primitives.

Option B is wrong because privileged mode disables isolation and grants all capabilities plus host device access, dramatically increasing breakout risk. Option C is wrong because mounting host /proc and /sys read-write exposes host kernel and process information and allows tampering, which weakens rather than strengthens isolation.

Exam trap

KCSA often tests the misconception that 'privileged mode' or host mounts improve performance/security; candidates must recognize these as anti-patterns that enable breakout, not prevent it.

Full explanation →
148
MCQeasy

Which Kubernetes component manages the assignment of pending pods to healthy worker nodes based on resource availability and constraints?

A.kube-proxy
B.kube-scheduler
C.kube-apiserver
D.etcd
AnswerB

kube-scheduler watches for unscheduled pods and binds each to a node that satisfies resource requests, affinity and taints. This satisfies the stem's requirement for the component assigning pending pods to healthy workers based on availability and constraints.

Why this answer

kube-scheduler watches for newly created Pods that have no node assigned and selects a node for them to run on. It filters nodes through predicates (resource requests, taints/tolerations, node affinity, topology spread) and then scores the remaining candidates to pick the best fit. The result is written back to the API server as a binding.

Exam trap

The trap here is confusing the control-plane components' responsibilities — candidates often pick kube-apiserver because it 'handles everything', but scheduling is exclusively kube-scheduler's job.

How to eliminate wrong answers

Option A is wrong because kube-proxy programs iptables/IPVS rules for Service traffic on each node — it does not place Pods. Option C is wrong because kube-apiserver is the REST front end that persists objects to etcd and validates requests; it does not choose nodes. Option D is wrong because etcd is the distributed key-value store backing the cluster state, not a scheduling component.

Full explanation →
149
MCQhard

You are troubleshooting a service mesh traffic split policy where telemetry shows that unauthorized external clients are bypassing the service mesh ingress gateway and directly accessing backend services via NodePort services. Which Kubernetes feature should you configure to prevent direct NodePort access to these sensitive pods?

A.Enabling anonymous authentication in kube-apiserver
B.Changing the service type from NodePort to ClusterIP
C.Increasing the API server request rate limit
D.NetworkPolicies restricting pod ingress traffic exclusively to the service mesh gateway pod selector
AnswerD

NetworkPolicies select pods by label and filter ingress at the CNI level, so only traffic from the gateway's pod selector reaches the backends. This blocks NodePort traffic arriving from any other source, closing the bypass the telemetry revealed.

Why this answer

NetworkPolicies restricting pod ingress traffic exclusively to the service mesh gateway pod selector (D) prevents direct NodePort access by only allowing traffic from the gateway. This enforces that all external traffic must go through the mesh ingress, where policies like mTLS and authorization are applied.

Exam trap

The trap is thinking that changing the service type or enabling authentication on the API server solves the bypass. Candidates must understand that NetworkPolicies are the correct tool to restrict pod-level ingress, and that service mesh security depends on enforcing that all traffic goes through the mesh.

How to eliminate wrong answers

Option A is wrong because enabling anonymous authentication on kube-apiserver weakens security and does not restrict NodePort access; it allows unauthenticated API requests. Option B is wrong because changing the service type from NodePort to ClusterIP would prevent external access entirely, but the requirement is to allow access only via the service mesh gateway, not to eliminate external access. Option C is wrong because increasing the API server request rate limit has no effect on NodePort traffic and does not address the security bypass.

Full explanation →
150
Multi-Selectmedium

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

Select 3 answers
A.Employ trusted base images from verified publishers
B.Implement vulnerability scanning in the CI/CD pipeline and registry
C.Store plaintext passwords directly inside Dockerfile ENV directives
D.Rely exclusively on public unverified base images to speed up development
E.Use digitally signed images to verify provenance and integrity
AnswersA, B, E

NIST SP 800-190 advises building images from trusted, verified base images to reduce inherited vulnerabilities and untrusted content. This directly addresses the image provenance risk in the pipeline, satisfying the framework's recommendation for controlling image sources.

Why this answer

NIST SP 800-190 Section 3.1 (Image Vulnerabilities) recommends using trusted base images from verified publishers (A) to reduce the risk of inheriting vulnerabilities or malicious code from untrusted sources, since every layer of a container image becomes part of the running container. The framework also calls for vulnerability scanning throughout the image lifecycle, including in the CI/CD pipeline and the registry (B), so that known CVEs are detected before deployment and continuously re-evaluated as new vulnerabilities are disclosed. Additionally, NIST SP 800-190 recommends digitally signing images and verifying those signatures (E) to establish provenance and integrity, ensuring that only images from authorized sources are deployed and that images have not been tampered with.

Option C is incorrect because storing plaintext passwords in Dockerfile ENV directives exposes secrets in image layers and metadata, directly violating NIST guidance on protecting secrets. Option D is incorrect because relying exclusively on public unverified base images increases supply-chain risk and contradicts the recommendation to use trusted, verified image sources.

Exam trap

KCSA often tests whether candidates conflate 'using containers' with 'securing containers' — the trap is picking convenience-oriented answers (public images, plaintext env vars) that speed development but violate NIST SP 800-190's explicit provenance, scanning, and secrets-management requirements.

Full explanation →
Page 1

Page 2 of 4

Page 3

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 →