Kubernetes and Cloud Native Security Associate (KCSA, CNCF) (KCSA) KCSA Questions 226–292 | Page 4/4

226

MCQeasy

A developer accidentally committed plain-text database passwords into a public Git repository. The password was stored in a Kubernetes Secret manifest. What immediate remediation step should be taken regarding the Secret?

A.Apply a DenyAll NetworkPolicy to the namespace.

B.Delete the Secret object and restart all cluster nodes.

C.Rotate the credential in the underlying database, then update the Kubernetes Secret with the new value.

D.Change the Secret manifest encoding from base64 to hex format.

AnswerC

Once a credential is exposed in a public repository it must be treated as compromised, so rotating the password in the underlying database invalidates the leaked value. Updating the Kubernetes Secret afterwards keeps the cluster functional while ensuring the exposed credential can no longer authenticate.

Why this answer

Once a credential is exposed in a public repository, it must be treated as compromised — the only safe remediation is to rotate the password in the database and update the Kubernetes Secret with the new value. Deleting or re-encoding the Secret does nothing because the old password remains valid in the database and is already in Git history.

Exam trap

The trap is treating Secret deletion or re-encoding as remediation — candidates miss that the credential itself must be rotated at the source, since the leaked value remains valid regardless of what happens to the Kubernetes object.

How to eliminate wrong answers

Option A is wrong because a DenyAll NetworkPolicy only blocks network traffic to pods — it does not invalidate the leaked credential or prevent an attacker who already has it from using it directly against the database. Option B is wrong because deleting the Secret and restarting nodes does not change the database password; the credential is still valid and the Git history still contains it. Option D is wrong because changing base64 to hex is cosmetic — both are trivially reversible encodings, not encryption, and the plaintext password is still recoverable.

Full explanation →

227

MCQmedium

A DevOps team is building container images using Dockerfiles. They decide to use official minimal distroless base images instead of standard Ubuntu images containing package managers and shell utilities. Which security benefit does this provide?

A.It reduces the container attack surface by removing unused binaries and shells

B.It encrypts the container image layers at rest in the registry

C.It automatically configures cloud IAM roles for the container

D.It guarantees zero vulnerabilities in application code dependencies

AnswerA

Distroless images omit package managers, shells and unused binaries, directly shrinking the exploitable attack surface. With fewer executables present, attackers cannot pivot via shell access or install tooling after compromise, satisfying the stem's requirement to reduce risk compared with Ubuntu images that ship these utilities by default.

Why this answer

Distroless images contain only the application and its runtime dependencies — no package manager, no shell, no standard Linux utilities. Removing these components eliminates entire classes of attack vectors such as shell injection, package-manager abuse, and exploitation of unpatched utilities like bash or curl. This directly reduces the container attack surface, which is exactly what option A states.

Exam trap

The trap is assuming 'distroless' or 'minimal' means 'secure by default' — candidates pick options claiming automatic encryption or zero vulnerabilities, but distroless only reduces the OS-level attack surface, not application code or registry-side concerns.

How to eliminate wrong answers

Option B is wrong because image encryption at rest is a registry/repository feature (e.g., ECR encryption, Artifact Registry CMEK) and has nothing to do with the base image choice — distroless images are not automatically encrypted. Option C is wrong because IAM role configuration is handled by the orchestrator (Kubernetes service accounts, workload identity) or cloud metadata services, not by the base image contents. Option D is wrong because distroless images only reduce OS-level vulnerabilities; application dependencies (npm, pip, Maven packages) still carry their own CVEs and must be scanned separately with tools like Trivy or Grype.

Full explanation →

228

MCQeasy

Why is running containers as the root user discouraged in Kubernetes platform security best practices?

A.It prevents the kubelet from starting the pod

B.It disables network policy enforcement

C.It stops container image vulnerability scanning

D.It increases the impact of potential container breakout or compromise by granting root privileges inside the container

AnswerD

Root inside a container maps to a privileged UID; if the container escapes via a kernel or runtime flaw, the attacker inherits those root capabilities on the host. Running as a non-root user constrains the privileges available after compromise.

Why this answer

Running containers as root is discouraged because if an attacker compromises the container, they gain root privileges inside it. This significantly increases the impact of a container breakout or lateral movement, as root can modify files, install tools, and potentially exploit kernel vulnerabilities to escape to the host. Kubernetes security best practices, such as those in the CIS Benchmarks and Pod Security Standards, therefore recommend running containers as non-root users to enforce least privilege.

Exam trap

KCSA often tests the misconception that running as root directly causes pod failure or disables security features like network policies, when the real risk is the increased blast radius upon compromise.

How to eliminate wrong answers

Option A is wrong because the kubelet does not prevent pods from starting based on the user ID; it starts containers regardless of whether they run as root or non-root. Option B is wrong because network policy enforcement is handled by the CNI plugin and is independent of the user ID inside the container; running as root does not disable it. Option C is wrong because container image vulnerability scanning is performed by external tools (e.g., Trivy, Clair) and is not affected by the runtime user; scanning occurs on the image, not the running container.

Full explanation →

229

MCQmedium

A security engineer is reviewing a Kubernetes cluster and finds that the API server is using the default admission control chain without any webhook-based admission plugins enabled. The engineer wants to ensure that all pod creation requests are validated against a custom policy that prevents privileged containers. Which admission plugin should be enabled and configured to achieve this?

A.NodeRestriction

B.MutatingAdmissionWebhook

C.ValidatingAdmissionWebhook

D.PodSecurityPolicy

AnswerC

ValidatingAdmissionWebhook allows the API server to send admission requests to an external HTTP callback that can validate objects against custom policies, such as blocking privileged containers. It is configured via a ValidatingWebhookConfiguration resource, and it can reject requests that violate the policy. This is the correct mechanism for enforcing custom validation logic without modifying Kubernetes source code.

Why this answer

To enforce custom validation policies such as blocking privileged containers, the API server must be able to call an external webhook that evaluates the request. ValidatingAdmissionWebhook enables this by forwarding admission requests to a configured HTTP endpoint, which can then allow or deny based on arbitrary logic. This is the standard extension point for policy enforcement in Kubernetes, often used by tools like Open Policy Agent Gatekeeper.

Exam trap

The trap here is assuming that PodSecurityPolicy is still available and can be used for pod security enforcement, when it has been removed in recent Kubernetes versions.

Full explanation →

230

MCQmedium

An administrator wants to ensure that no container in a specific namespace runs with a root User ID (UID 0). Which security context setting should be enforced?

A.privileged: false

B.readOnlyRootFilesystem: true

C.runAsNonRoot: true

D.allowPrivilegeEscalation: false

AnswerC

runAsNonRoot: true forces the kubelet to validate that the container's specified user is not UID 0 before starting it, rejecting the pod otherwise. This enforces the namespace requirement that no container runs as root, unlike runAsUser which merely sets a specific UID.

Why this answer

The runAsNonRoot: true security context setting instructs the kubelet to validate at container start that the image's USER is not UID 0, and to refuse to start the container if it would run as root. Setting it at the pod or container level enforces the no-root requirement across the namespace when combined with Pod Security Admission's restricted profile.

Exam trap

KCSA often tests whether candidates conflate privilege controls — the trap is choosing privileged: false or allowPrivilegeEscalation: false, which restrict capabilities but do not prevent a container from running as UID 0.

How to eliminate wrong answers

Option A is wrong because privileged: false only prevents the container from gaining elevated Linux capabilities and host access — a container can still run as UID 0 with privileged: false. Option B is wrong because readOnlyRootFilesystem: true makes the container's root filesystem immutable, which is a filesystem integrity control unrelated to the user ID the process runs as. Option D is wrong because allowPrivilegeEscalation: false blocks setuid/setgid binaries from gaining more privileges than the parent process, but it does not prevent the container from starting as UID 0 in the first place.

Full explanation →

231

Multi-Selecthard

Which TWO statements are true regarding Kubernetes NetworkPolicy default behaviors?

Select 2 answers

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

B.By default, all pods in a cluster are non-isolated and accept traffic from any source.

C.When a NetworkPolicy selects a pod and specifies ingress rules, unallowed ingress traffic is blocked.

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

E.NetworkPolicies apply to cluster nodes rather than individual pods.

AnswersB, C

NetworkPolicy is additive and namespace-scoped. Until a policy selects a pod, that pod is non-isolated and accepts all ingress and egress traffic from any source, so clusters without policies behave as fully open by default.

Why this answer

Option B is correct because Kubernetes starts with a flat, non-isolated network model: unless a NetworkPolicy selects a pod, that pod is non-isolated and accepts ingress from any source and sends egress to any destination. Option C is correct because once a NetworkPolicy selects a pod and defines ingress rules, the pod becomes isolated for ingress, so only traffic explicitly allowed by those rules (plus established return traffic) is permitted and all other ingress is denied. Option A is wrong because NetworkPolicies are namespaced, additive, and opt-in; installing a cluster does not create any policies or block cross-namespace traffic by default.

Option D is wrong because egress is also non-isolated by default—egress is only restricted when a policy selects the pod and includes egress rules (egress isolation). Option E is wrong because NetworkPolicies select pods (via podSelector) within a namespace, not cluster nodes; node-level filtering is handled by other mechanisms such as iptables, nftables, or cloud security groups.

Exam trap

The trap is assuming that NetworkPolicies are active by default or that they block all traffic upon creation, when in fact they only affect pods they select and only for the specified directions.

Full explanation →

232

Multi-Selecteasy

Which TWO actions help secure Ingress traffic in a Kubernetes cluster? (Choose two)

Select 2 answers

A.Exposing all internal debugging endpoints via unencrypted HTTP on port 80

B.Enforcing TLS termination with strong cipher suites and valid certificates

C.Disabling all authentication mechanisms at the ingress gateway

D.Restricting ingress controller exposure and using Web Application Firewalls (WAF)

E.Storing TLS private keys in plaintext ConfigMaps

AnswersB, D

Enforcing TLS termination with strong cipher suites and valid certificates encrypts data in transit at the Ingress controller, satisfying the requirement to secure external traffic entering the cluster. This prevents eavesdropping and man-in-the-middle attacks on HTTP routes, directly addressing the stem's Ingress security constraint.

Why this answer

Option B is correct because enforcing TLS termination at the ingress layer with strong cipher suites and valid certificates encrypts client-to-cluster traffic and prevents downgrade or weak-crypto attacks, directly securing Ingress traffic. Option D is correct because restricting the ingress controller's exposure (e.g., limiting its Service to a LoadBalancer with tight firewall rules or a private IP) and placing a WAF in front of it filters malicious HTTP/HTTPS requests such as SQLi and XSS before they reach backend pods. Option A is wrong because exposing debugging endpoints over unencrypted HTTP on port 80 increases the attack surface and leaks sensitive data.

Option C is wrong because disabling authentication at the ingress gateway removes access control, allowing anonymous or unauthorized users to reach services. Option E is wrong because storing TLS private keys in plaintext ConfigMaps exposes them to anyone with read access to the namespace, breaking key confidentiality.

Exam trap

KCSA often tests the assumption that any HTTP exposure is acceptable if internal, or that authentication can be safely disabled at the edge, when in fact encryption, authentication, and exposure restriction are all required for secure ingress.

Full explanation →

233

MCQmedium

You are hardening etcd and want to ensure that sensitive data stored in Kubernetes secrets is encrypted at rest within etcd. Which API server configuration file parameter specifies how secrets should be encrypted?

A.--etcd-encryption-key

B.--secrets-encryption-enabled

C.--encryption-provider-config

D.--etcd-ca-file

AnswerC

The `--encryption-provider-config` flag points the API server to an EncryptionConfiguration file, which defines the providers (such as `aescbc` or KMS v2) used to encrypt Secret resources before they are written to etcd. This directly satisfies the requirement for encryption at rest within etcd, unlike flags governing transport or authorisation.

Why this answer

The kube-apiserver flag --encryption-provider-config points to an EncryptionConfiguration YAML file that defines which resources (e.g., secrets) are encrypted and which providers (aescbc, aesgcm, kms, secretbox, identity) are used. This is the only supported mechanism for encrypting Kubernetes Secrets at rest in etcd. Without it, secrets are stored as base64-encoded plaintext in etcd.

Exam trap

KCSA often tests whether candidates invent plausible-sounding flag names, so the trap is choosing a boolean-sounding flag like --secrets-encryption-enabled instead of the actual file-path flag --encryption-provider-config.

How to eliminate wrong answers

Option A is wrong because --etcd-encryption-key is not a real kube-apiserver flag; encryption keys are defined inside the EncryptionConfiguration file referenced by --encryption-provider-config. Option B is wrong because --secrets-encryption-enabled does not exist — there is no boolean toggle for secret encryption; you must supply a provider config. Option D is wrong because --etcd-ca-file configures the CA certificate used to verify the etcd server's TLS identity, which is unrelated to at-rest encryption of secret data.

Full explanation →

234

Multi-Selectmedium

An auditor evaluates network security controls in a Kubernetes cluster. Which TWO configurations help mitigate lateral movement and network-based attacks between pods?

Select 2 answers

A.Disabling CNI network plugins to run pods in bridge mode

B.Implementing a service mesh (such as Istio or Linkerd) with strict mTLS enforcement

C.Exposing all internal microservices via NodePort services on worker nodes

D.Mounting the host network namespace (`hostNetwork: true`) on all application pods

E.Enforcing Kubernetes NetworkPolicies to restrict pod-to-pod ingress and egress traffic

AnswersB, E

A service mesh with strict mTLS authenticates and encrypts all pod-to-pod traffic via sidecar proxies, rejecting unauthenticated connections. This prevents a compromised pod from impersonating others or intercepting traffic, directly mitigating lateral movement and network-based attacks within the cluster.

Why this answer

Option B is correct because a service mesh such as Istio or Linkerd with strict mTLS enforcement authenticates and encrypts all service-to-service traffic, so a compromised pod cannot impersonate another workload or sniff plaintext traffic, directly limiting lateral movement. Option E is correct because Kubernetes NetworkPolicies implement pod-level, label-selector-based ingress and egress filtering enforced by the CNI, allowing only explicitly permitted pod-to-pod flows and blocking unauthorized east-west connections. Option A is wrong because disabling CNI plugins and using plain bridge mode removes policy enforcement and segmentation, increasing exposure rather than mitigating it.

Option C is wrong because NodePort services expose internal microservices on every worker node's IP and port range, widening the attack surface instead of containing it. Option D is wrong because hostNetwork: true places pods in the node's network namespace, letting them see node traffic and bypass pod network isolation, which enables rather than prevents lateral movement.

Exam trap

KCSA often tests the misconception that hostNetwork or NodePort improves connectivity/security, when in fact they expand the attack surface — the correct mitigations are NetworkPolicies and mTLS-enabled service meshes.

Full explanation →

235

Multi-Selecthard

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

Select 3 answers

A.RBAC (Role-Based Access Control) authorizer.

B.Node authorizer for restricting kubelet operations.

C.Etcd consensus authorizer.

D.Kube-proxy IPVS routing authorizer.

E.Webhook authorizer for external authorization evaluation.

AnswersA, B, E

The RBAC authorizer evaluates RoleBindings and ClusterRoleBindings to decide whether an authenticated identity may perform a requested verb on a resource. It is one of the API server's built-in authorisation modes, satisfying the requirement for post-authentication access control.

Why this answer

The Kubernetes API server supports multiple authorization modes that are evaluated in order after authentication: RBAC (A) grants or denies access based on Roles, ClusterRoles, RoleBindings, and ClusterRoleBindings, making it the standard mechanism for user and service account permissions. The Node authorizer (B) is a specialized authorizer that restricts what kubelets can do, allowing each node to access only the resources (such as its own Pods, Secrets, and ConfigMaps) needed to run its workloads. The Webhook authorizer (E) sends SubjectAccessReview requests to an external HTTP service for authorization decisions, enabling integration with third-party policy engines like OPA/Gatekeeper.

Etcd consensus authorizer (C) does not exist; etcd is the backing datastore and has no role in authorizing API requests. Kube-proxy IPVS routing authorizer (D) is fictitious; kube-proxy implements Service load balancing via iptables or IPVS but is not an authorization mechanism.

Exam trap

KCSA often tests the distinction between authentication, authorization, and admission control, and candidates may mistakenly include etcd or kube-proxy as authorizers because they are core components, but they do not perform authorization.

Full explanation →

236

MCQeasy

Which RBAC verb allows a user to delete an existing resource in a Kubernetes namespace?

A.delete

B.remove

C.purge

D.destroy

AnswerA

The `delete` verb in Kubernetes RBAC explicitly authorises removal of existing resources, satisfying the stem's requirement to delete a resource within a namespace. It maps directly to the HTTP DELETE method on resource endpoints, distinguishing it from `create`, `update`, or `patch`, which cannot remove objects.

Why this answer

In Kubernetes RBAC, the verb 'delete' is the canonical action that authorizes removal of an existing resource within a namespace (or cluster-scoped resource). It is one of the standard verbs alongside get, list, watch, create, update, patch, and deletecollection. A Role or ClusterRole rule such as 'verbs: ["delete"]' on a resource like pods grants the subject permission to issue DELETE requests against that resource's API endpoint.

Exam trap

The trap is that candidates may pick a synonym like 'remove', 'purge', or 'destroy' because they sound like deletion actions, but Kubernetes RBAC only recognizes the exact verb 'delete' (and 'deletecollection') — verb names are case-sensitive API tokens, not natural-language descriptions.

How to eliminate wrong answers

Option B is wrong because 'remove' is not a recognized Kubernetes RBAC verb — it is not part of the API verb set and would be rejected or simply never match an authorization check. Option C is wrong because 'purge' is not an RBAC verb; it is not defined in the Kubernetes authorization model and has no meaning in Role/ClusterRole rules. Option D is wrong because 'destroy' is not an RBAC verb either; while it sounds destructive, Kubernetes uses 'delete' and 'deletecollection' for removal operations, and 'destroy' would never authorize any API action.

Full explanation →

237

MCQmedium

A security engineer needs to verify that control plane component pods (such as kube-apiserver and etcd) have correct file ownership on the control plane node. According to CIS benchmarks, who should own these manifest files located in "/etc/kubernetes/manifests"?

A.nobody:nogroup

B.root:root

C.daemon:daemon

D.kube:kube

AnswerB

CIS benchmarks mandate root:root ownership for control plane static pod manifests in /etc/kubernetes/manifests, including kube-apiserver and etcd definitions. This prevents unprivileged users from modifying pod specifications, which could otherwise alter API server flags or etcd configuration and compromise the entire cluster's control plane integrity.

Why this answer

CIS Kubernetes Benchmark requires that control plane manifest files in /etc/kubernetes/manifests (static pod manifests for kube-apiserver, etcd, kube-controller-manager, kube-scheduler) be owned by root:root with permissions 644 or more restrictive. This prevents unprivileged users from modifying critical control plane definitions.

Exam trap

KCSA often tests the assumption that Kubernetes service accounts like kube:kube own control plane files, when in fact CIS benchmarks mandate root:root for all static pod manifests.

How to eliminate wrong answers

Option A is wrong because nobody:nogroup is used for unprivileged daemons, not for critical control plane files; assigning these files to nobody would allow any process running as nobody to tamper with the API server or etcd. Option C is wrong because daemon:daemon is a legacy Unix account for background services and is not the CIS-mandated owner for Kubernetes control plane manifests. Option D is wrong because kube:kube is not a standard system account on control plane nodes; Kubernetes components run as root in static pods, and the files must be root-owned to prevent privilege escalation.

Full explanation →

238

Multi-Selecthard

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

Select 2 answers

A.Enabling Webhook authorization mode so kubelet requests are validated against API server RBAC.

B.Removing all TLS certificates from the kubelet configuration.

C.Setting kubelet authorization mode to AlwaysAllow.

D.Disabling anonymous authentication on the kubelet.

E.Enabling the kubelet read-only port 10255.

AnswersA, D

Webhook authorization makes the kubelet call the API server's SubjectAccessReview endpoint for each request, so cluster RBAC policies govern who may query the kubelet API. This centralises access control, preventing unauthorised container inspection via direct kubelet connections.

Why this answer

Option A is correct because setting the kubelet's authorization mode to Webhook makes the kubelet send SubjectAccessReview requests to the API server, so access decisions are evaluated against API server RBAC policies rather than being granted blindly. Option D is correct because disabling anonymous authentication (--anonymous-auth=false) forces unauthenticated requests to the kubelet's HTTPS endpoint to be rejected with 401, preventing anonymous users from querying endpoints like /pods that could expose container details. Option B is wrong because removing TLS certificates would break kubelet authentication and encryption, making the API less secure, not more.

Option C is wrong because AlwaysAllow authorizes every request without any check, which is the opposite of securing the kubelet. Option E is wrong because the read-only port 10255 serves unauthenticated, unencrypted data and should be disabled, not enabled.

Exam trap

The trap is confusing authentication and authorization mechanisms, or thinking that AlwaysAllow or the read-only port improve security, when they actually weaken it.

Full explanation →

239

MCQeasy

Where are static pods for a control plane node typically defined so that the kubelet can automatically create and manage them?

A.In the directory specified by staticPodPath in the kubelet configuration file (default /etc/kubernetes/manifests).

B.In the ~/.kube/config file of the root user.

C.In the etcd database under the /registry/staticpods prefix.

D.In the kube-system namespace as standard Deployment objects.

AnswerA

The kubelet watches the directory named by staticPodPath in its configuration file, by default /etc/kubernetes/manifests, and creates pods from any manifests placed there. This satisfies the stem's requirement for automatic creation and management without the API server, since the kubelet reads local files directly rather than relying on control plane scheduling.

Why this answer

Static pods are defined as YAML manifest files placed in the directory specified by the 'staticPodPath' setting in the kubelet configuration (default /etc/kubernetes/manifests). The kubelet watches this directory and automatically creates, updates, and manages pods from any manifests it finds there, without involving the API server scheduler.

Exam trap

KCSA often tests whether candidates confuse static pods with standard Deployments or DaemonSets, or assume static pod definitions live in etcd rather than on the node's filesystem.

How to eliminate wrong answers

Option B is wrong because ~/.kube/config is a kubeconfig file containing cluster connection details and credentials, not pod manifests. Option C is wrong because static pods are not stored in etcd under a '/registry/staticpods' prefix — the kubelet creates a mirror pod in the API server for visibility, but the source of truth is the local manifest file. Option D is wrong because static pods are not Deployment objects and do not live in the kube-system namespace as Deployments; they are managed directly by the kubelet on the node.

Full explanation →

240

Multi-Selectmedium

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

Select 3 answers

A.Requiring all capabilities to be dropped except NET_BIND_SERVICE or dropping all (capabilities.drop: [ALL])

B.Requiring containers to run as a non-root user (runAsNonRoot: true)

C.Disallowing privilege escalation (allowPrivilegeEscalation: false)

D.Allowing unrestricted use of the host network and host PID namespaces

E.Enabling privileged mode for all standard workloads

AnswersA, B, C

Restricted builds on baseline by requiring containers to drop all Linux capabilities, permitting only NET_BIND_SERVICE to be added back. This capability restriction limits the kernel privileges a compromised container can exploit, satisfying the Restricted profile's hardening requirement.

Why this answer

The Restricted Pod Security profile is the most stringent of the three Pod Security Standards and enforces hardening controls on every container. Option A is correct because Restricted requires that Linux capabilities be dropped, either by dropping ALL (capabilities.drop: [ALL]) or by dropping all except NET_BIND_SERVICE, preventing containers from retaining dangerous privileges. Option B is correct because Restricted mandates runAsNonRoot: true, ensuring containers do not run as UID 0 (root), which limits the impact of a container compromise.

Option C is correct because Restricted requires allowPrivilegeEscalation: false, blocking processes from gaining more privileges than their parent (for example via setuid binaries or file capabilities). Options D and E are incorrect because allowing host network/host PID namespaces and enabling privileged mode are explicitly forbidden by the Restricted profile (and privileged mode is only permitted under the Privileged profile), so they do not represent enforced Restricted controls.

Exam trap

The trap here is confusing Baseline and Restricted controls; candidates often think host namespaces or privileged mode are allowed under Restricted when they are explicitly forbidden.

Full explanation →

241

MCQmedium

Under the Pod Security Standards, a developer attempts to deploy a pod with 'privileged: true' in a namespace labeled with 'pod-security.kubernetes.io/enforce=baseline'. What will happen?

A.The admission controller will reject the pod creation request with an error.

B.The pod will run in a restricted sandbox environment automatically.

C.The pod will be created successfully, but a warning will be logged in the audit log.

D.The kubelet will automatically strip the 'privileged: true' setting and run the pod safely.

AnswerA

The Baseline policy explicitly prohibits privileged containers, so the Pod Security admission controller blocks the request at admission time and returns an error. Enforcement occurs before the pod is persisted, meaning no workload is scheduled — satisfying the stem's enforced baseline constraint rather than merely warning or auditing the violation.

Why this answer

The baseline Pod Security Standard explicitly prohibits privileged containers, so the Pod Security Admission controller will reject the pod creation request when the namespace enforces baseline. The 'enforce' label triggers rejection (not just warning) for any pod violating the baseline policy. Privileged mode is one of the restricted fields baseline forbids.

Exam trap

The trap here is confusing the three PSA label modes — candidates pick 'warning logged' (warn mode) or 'audit log entry' (audit mode) when the question specifies enforce, which always rejects non-compliant pods.

How to eliminate wrong answers

Option B is wrong because Pod Security Standards do not automatically sandbox or downgrade a pod's privileges; they either admit or reject the pod based on the enforce level. Option C is wrong because warnings are produced by the 'warn' label mode, not 'enforce'; with enforce=baseline the request is denied outright, not merely logged. Option D is wrong because the kubelet does not mutate or strip securityContext fields; admission control happens at the API server before scheduling, and no component silently rewrites privileged:true.

Full explanation →

242

Multi-Selecteasy

Which TWO entities can be assigned RBAC permissions in a Kubernetes cluster? (Choose TWO)

Select 2 answers

A.ConfigMap

B.Namespace

C.ServiceAccount

D.PersistentVolume

E.User

AnswersC, E

ServiceAccounts are namespaced identities used by pods to authenticate to the API server, and they can be bound to Roles or ClusterRoles via RoleBindings. This makes them a valid RBAC subject, satisfying the stem's requirement for entities assignable permissions.

Why this answer

In Kubernetes RBAC, permissions are granted to subjects (the "who") via RoleBindings or ClusterRoleBindings, and the two subject types listed here are ServiceAccount (C) and User (E). A ServiceAccount (C) is a namespaced identity used by Pods and controllers, and it can be bound to Roles or ClusterRoles so workloads receive specific API permissions. A User (E) represents a human or external identity authenticated by the cluster (for example via client certificates or an OIDC provider) and can likewise be referenced as a subject in RoleBinding/ClusterRoleBinding.

By contrast, ConfigMap (A), Namespace (B), and PersistentVolume (D) are API resources/objects that permissions are granted on (the "what"), not subjects that can be assigned permissions.

Exam trap

KCSA often tests the distinction between RBAC subjects and RBAC resources — candidates frequently pick Namespace or ConfigMap because they appear in RoleBinding YAML, but only User, Group, and ServiceAccount are valid subjects.

Full explanation →

243

MCQhard

You are performing a security assessment on an existing Kubernetes cluster. You discover that the kubelet API permits users with valid service account tokens to read sensitive container environment variables and logs. How should you configure the kubelet authorization mode to prevent unauthorized token holders from reading arbitrary pod data?

A.Set kubelet authorization mode to Webhook so the API server evaluates RBAC permissions for kubelet requests.

B.Set kubelet authorization mode to AlwaysAllow.

C.Enable anonymous access on port 10250.

D.Disable the kubelet authentication certificate.

AnswerA

Webhook authorization makes the Kubelet delegate each request to the API server, which evaluates RBAC permissions for the requesting identity. Token holders then only read pod data their roles permit, rather than any pod on the node.

Why this answer

Setting the kubelet authorization mode to Webhook delegates authorization decisions to the API server, which evaluates RBAC policies for the requesting user or service account. This ensures that only identities with explicit RBAC permissions can access kubelet endpoints like /pods, /logs, or /exec. By default, kubelet may use AlwaysAllow, which grants full access to any authenticated user, including service account tokens, leading to the vulnerability described.

Exam trap

KCSA often tests the misconception that authentication alone is sufficient, but the trap is that authorization mode must be Webhook to enforce RBAC; AlwaysAllow is a dangerous default that many candidates overlook.

How to eliminate wrong answers

Option B is wrong because AlwaysAllow grants unrestricted access to all authenticated requests, which is the opposite of what is needed and would worsen the security issue. Option C is wrong because enabling anonymous access on port 10250 would allow unauthenticated users to access sensitive data, directly contradicting the goal. Option D is wrong because disabling kubelet authentication certificates would break the authentication mechanism entirely, potentially allowing unauthorized access or disrupting cluster operations.

Full explanation →

244

MCQmedium

An auditor notices that a cluster allows users to create Pods that mount host paths (`hostPath`). Which threat does this pose to the underlying node integrity?

A.Arbitrary read/write access to the host filesystem, enabling node compromise

B.Automatic failure of Kubernetes liveness and readiness health probes

C.Inability of the CNI plugin to assign IP addresses to pods

D.Immediate corruption of the etcd distributed consensus state

AnswerA

A `hostPath` volume bind-mounts a directory from the node's filesystem directly into the Pod, bypassing container isolation. Without a read-only flag or restrictive `allowedHostPaths` policy, a workload can read or overwrite sensitive node files such as kubelet credentials or system binaries, escalating to full node compromise.

Why this answer

A hostPath volume mounts a directory or file from the node's filesystem directly into the pod, so a container with write access can modify critical node files such as /etc/cron.d, /var/lib/kubelet, or SSH keys, leading to full node compromise and potential cluster-wide lateral movement. This is why Pod Security Standards restricted mode and admission policies like OPA Gatekeeper or Kyverno commonly block hostPath usage.

Exam trap

KCSA often tests whether candidates understand that hostPath is a node-integrity risk, not a pod-scheduling or networking concern, luring them toward plausible-sounding but unrelated options about probes, CNI, or etcd.

How to eliminate wrong answers

Option B is wrong because liveness and readiness probes are HTTP/TCP/exec health checks managed by the kubelet — hostPath mounts have no relationship to probe execution or failure. Option C is wrong because CNI plugins assign pod IPs from the pod CIDR independent of volume mounts; hostPath does not interfere with IPAM. Option D is wrong because etcd stores cluster state and is accessed only by the API server — a hostPath mount inside a pod does not directly corrupt etcd's consensus or data.

Full explanation →

245

MCQhard

A security team is implementing NIST SP 800-190 guidelines for container runtime security. Which kernel feature is leveraged by container runtimes to restrict system calls and meet least-privilege execution requirements?

A.Seccomp profiles

B.cgroups v2

C.AppArmor MAC profiles

D.Namespaces

AnswerA

Seccomp profiles restrict the system calls a container process may invoke, enforcing least-privilege execution at the kernel level. NIST SP 800-190 recommends this syscall filtering to reduce the container attack surface, satisfying the runtime restriction requirement.

Why this answer

Seccomp (secure computing mode) profiles are the kernel feature that filters which system calls a container process may invoke, directly enforcing least-privilege execution at the syscall boundary. NIST SP 800-190 explicitly calls out seccomp as a runtime control to reduce the kernel attack surface. By applying a seccomp profile (e.g., RuntimeDefault or a custom allowlist), the runtime blocks dangerous syscalls like ptrace or mount that a compromised container might abuse.

Exam trap

KCSA often tests the confusion between isolation primitives (namespaces), resource controls (cgroups), MAC frameworks (AppArmor/SELinux), and syscall filtering (seccomp) — candidates frequently pick namespaces or AppArmor when the question specifically asks about restricting system calls.

How to eliminate wrong answers

Option B is wrong because cgroups v2 handles resource accounting and limits (CPU, memory, I/O), not syscall filtering — it does not restrict which kernel operations a process can perform. Option C is wrong because AppArmor is a Mandatory Access Control system that confines programs by path and capability profiles, not by syscall filtering; it complements but does not replace seccomp. Option D is wrong because namespaces provide isolation of views (PID, network, mount, user) but do not restrict the set of syscalls a process can call — a container in its own namespace can still invoke any syscall the kernel allows.

Full explanation →

246

Multi-Selectmedium

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

Select 2 answers

A.Kubernetes NetworkPolicy egress CIDR blocks

B.PersistentVolume claim capacity metadata

C.X509 Client Certificates presented during TLS handshakes

D.Container image pull secrets stored in private registries

E.Bearer Tokens (including ServiceAccount JWT tokens)

AnswersC, E

The API server validates client certificates presented during the TLS handshake against its configured certificate authority, extracting the subject's common name or organisation as the authenticated username. This is a native authentication mechanism satisfying the stem's requirement.

Why this answer

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

Exam trap

KCSA often tests whether candidates can distinguish authentication (who you are) from authorization (what you can do) and from unrelated controls like NetworkPolicy or image pull secrets — the trap is picking any security-sounding option instead of the two real authenticators.

Full explanation →

247

MCQmedium

A security engineer is reviewing the security posture of an enterprise Kubernetes deployment. They note that developers push container images directly to a private registry without vulnerability scanning. Which of the 4Cs is directly impacted by this gap?

A.Code layer

B.Cluster layer

C.Cloud layer

D.Container layer

AnswerD

The container layer covers image contents, so unscanned images pushed to the private registry leave vulnerabilities undetected within the artefacts themselves. This directly satisfies the stem's gap: no scanning occurs before images reach the registry, meaning the container layer's integrity is compromised regardless of cluster or cloud controls.

Why this answer

The Container layer is correct because the gap described — pushing images to a registry without vulnerability scanning — directly concerns the contents and integrity of container images. In the 4Cs model (Cloud, Cluster, Container, Code), the Container layer covers image provenance, image scanning, minimal base images, and runtime hardening. Unscanned images may contain known CVEs in OS packages or libraries, which is precisely a Container-layer concern.

Exam trap

KCSA often tests confusion between the 4Cs layers; candidates mistakenly attribute image scanning to the Code layer (because it involves code dependencies) or the Cluster layer (because it involves admission control), when the image itself is a Container-layer artifact.

How to eliminate wrong answers

Option A is wrong because the Code layer refers to application source code security (SAST, dependency scanning of application libraries, secure coding), not the container image build and registry workflow. Option B is wrong because the Cluster layer covers the control plane and worker node configuration — API server hardening, RBAC, network policies, admission controllers — not image scanning. Option C is wrong because the Cloud layer refers to the underlying IaaS/PaaS infrastructure (VPCs, IAM, hypervisor, managed service configuration), which is separate from image content.

Full explanation →

248

MCQhard

An attacker with compromised Kubernetes credentials attempts to hide malicious activity by deleting Kubernetes audit logs on the worker node. Where should audit logs ideally be stored and managed in a securely hardened cluster to prevent tampering and ensure non-repudiation?

A.Written to the container image layer cache of the local container runtime

B.Stored inside unencrypted ConfigMaps within the default namespace

C.Saved locally in an ephemeral emptyDir volume inside the kube-system namespace

D.Forwarded to an external centralized SIEM or secure remote storage backend

AnswerD

Node-local audit logs are writable by anyone with node or credential access, so an attacker can delete them. Forwarding to an external SIEM or remote backend removes that write path, preserving tamper-evident records for non-repudiation.

Why this answer

Audit logs must be shipped off-node to an external, append-only or WORM-capable backend (SIEM, syslog server, object storage with immutability) so that a compromised node or cluster credential cannot delete or alter them. Kubernetes audit policy is configured on the API server via --audit-policy-file and --audit-log-path/--audit-webhook-config-file, and forwarding to a remote endpoint preserves non-repudiation because the attacker's blast radius no longer includes the log store. Centralized storage also enables correlation across nodes and clusters, which is essential for forensic reconstruction after an incident.

Exam trap

The trap here is assuming that any log location inside the cluster (ConfigMap, emptyDir, node filesystem) is 'secure' — KCSA tests whether you recognize that tamper resistance and non-repudiation require the log store to be outside the attacker's control boundary.

How to eliminate wrong answers

Option A is wrong because the container image layer cache is a read-only, content-addressed store managed by the runtime (containerd/CRI-O) and is not a log destination at all — audit events are never written there. Option B is wrong because ConfigMaps are etcd-backed Kubernetes objects that any principal with write access to the default namespace can modify or delete, and they are not designed for high-volume append-only log streams. Option C is wrong because an emptyDir volume is ephemeral and node-local — it is destroyed when the pod is removed and is fully accessible to anyone with node or pod access, so it offers zero tamper resistance.

Full explanation →

249

MCQmedium

An administrator wants to prevent users from creating pods that mount the host network ('hostNetwork: true'). Which tool or feature is best suited to enforce this restriction natively across the cluster?

A.ResourceQuota limiting network interfaces

B.Pod Security admission controller with baseline or restricted profile

C.RBAC ClusterRole restricting pod creation

D.NetworkPolicy with a deny-all rule

AnswerB

Pod Security admission enforces the baseline and restricted profiles natively at the namespace level, and both explicitly forbid `hostNetwork: true` in their pod specifications. Labelling the target namespace with `pod-security.kubernetes.io/enforce` blocks such pods at admission time, satisfying the cluster-wide restriction without third-party tooling.

Why this answer

Pod Security admission (PSA) is the built-in Kubernetes admission controller that enforces Pod Security Standards at the namespace level using labels. The baseline and restricted profiles explicitly disallow hostNetwork: true, so labeling the namespace with pod-security.kubernetes.io/enforce: baseline (or restricted) blocks pods that request host networking. This is the native, cluster-wide enforcement mechanism.

Exam trap

KCSA often tests the confusion between RBAC (who can act) and admission control (what is allowed), tempting candidates to pick RBAC when the requirement is enforcing pod spec restrictions.

How to eliminate wrong answers

Option A is wrong because ResourceQuota limits resource consumption and object counts; it has no field to restrict network interfaces or hostNetwork. Option C is wrong because RBAC controls who can perform verbs on resources, not the contents of pod specs — a user with create pods permission can still submit a hostNetwork pod unless admission blocks it. Option D is wrong because NetworkPolicy governs pod-to-pod traffic flows, not whether a pod can join the host network namespace.

Full explanation →

250

MCQhard

A financial services company runs Kubernetes clusters in multiple regions. Their compliance team must demonstrate that cryptographic keys used for etcd encryption at rest are rotated according to a defined schedule and that access to these keys is logged. Which Kubernetes feature directly supports meeting this requirement?

A.Setting the --encryption-provider-config flag on kube-apiserver with a local aescbc key.

B.Enabling encryption at rest with a KMS provider plugin.

C.Deploying a service mesh with mutual TLS between all pods.

D.Configuring etcd to use TLS client certificate authentication.

AnswerB

Using a KMS provider plugin for encryption at rest allows the cluster to delegate key management to an external key management service. This enables automatic key rotation based on the KMS provider's policies and provides audit logs of key usage from the KMS. It directly addresses both rotation and access logging, which are core compliance requirements for cryptographic key management.

Why this answer

A KMS provider plugin integrates Kubernetes with an external key management system, enabling automated key rotation and detailed audit logs of key usage. This directly satisfies the compliance need for scheduled rotation and logged access. Local encryption keys require manual rotation and lack access logging.

TLS and service mesh options address transport security, not data-at-rest key management.

Exam trap

The trap here is assuming that any encryption mechanism satisfies key rotation and logging requirements, when only a KMS provider plugin offers the necessary lifecycle management and audit trails.

Full explanation →

251

MCQhard

A platform engineer needs to secure an Ingress resource using TLS termination, ensuring that sensitive private keys are stored securely within the cluster and referenced safely. Which Kubernetes resource should be created to store the TLS certificate and private key pair?

A.Secret of type kubernetes.io/tls

B.PersistentVolumeClaim

C.CertificateSigningRequest

D.ConfigMap

AnswerA

A kubernetes.io/tls Secret holds the certificate and private key as base64-encoded data, and the Ingress controller reads it directly for TLS termination. This satisfies the stem's constraint that keys stay inside the cluster and are referenced safely rather than embedded in the Ingress spec.

Why this answer

A Secret of type kubernetes.io/tls is the correct resource because it is specifically designed to hold a TLS certificate and its private key. The Ingress resource references this Secret in its tls section, and the ingress controller uses it to terminate TLS. Kubernetes treats this Secret type with appropriate handling for the required tls.crt and tls.key fields.

Exam trap

KCSA often tests the confusion between Secrets and ConfigMaps for sensitive data, and between CertificateSigningRequest (for issuing certs) and kubernetes.io/tls Secrets (for storing cert/key pairs used by Ingress).

How to eliminate wrong answers

Option B is wrong because a PersistentVolumeClaim provides storage, not secret storage — it cannot hold certificate/key data. Option C is wrong because a CertificateSigningRequest is used to request a certificate from a CA (e.g., for client certs or kubelet certs), not to store an existing TLS key pair for Ingress. Option D is wrong because a ConfigMap stores non-sensitive configuration data in plaintext and is not appropriate for private keys; using it would expose the key.

Full explanation →

252

MCQhard

You want to enable encryption at rest for Kubernetes Secrets in your cluster using an external KMS (Key Management Service) provider. Which component on the control plane reads the EncryptionConfiguration file and handles this encryption?

A.kube-controller-manager

B.kube-apiserver

C.kubelet

D.etcd daemon directly

AnswerB

The kube-apiserver reads the EncryptionConfiguration file and performs envelope encryption of Secrets before writing them to etcd, delegating data key wrapping to the external KMS provider. No other control plane component touches etcd writes, so this satisfies the requirement for KMS-backed encryption at rest.

Why this answer

The kube-apiserver is the only component that reads the EncryptionConfiguration file (passed via --encryption-provider-config) and performs envelope encryption of Secret data before writing to etcd. It encrypts on write and decrypts on read, so etcd only ever stores ciphertext for protected resources.

Exam trap

KCSA often tests which control-plane component owns a given function — candidates pick etcd or kube-controller-manager because they associate 'storage' or 'cluster management' with encryption, missing that only the API server handles it.

How to eliminate wrong answers

Option A is wrong because kube-controller-manager runs controllers (Deployment, ReplicaSet, Node) and does not touch the encryption pipeline. Option C is wrong because kubelet runs on worker nodes and manages pod lifecycle — it never writes Secrets to etcd. Option D is wrong because etcd is a passive key-value store; it has no knowledge of Kubernetes encryption providers and simply persists whatever bytes the API server sends.

Full explanation →

253

MCQeasy

An administrator needs to secure access to the Kubernetes API server from an external CI/CD pipeline. Which mechanism should be used to authenticate the pipeline using an existing external identity provider without embedding long-lived static tokens?

A.Store the administrative kubeconfig file in a public ConfigMap.

B.Configure the API server with --oidc-issuer-url and related flags to validate JSON Web Tokens issued by the IDP.

C.Enable anonymous requests on the API server for the CI/CD CIDR block.

D.Create a shared static password file and pass it via --basic-auth-file.

AnswerB

Configuring the API server with `--oidc-issuer-url` lets it validate JSON Web Tokens issued by the external identity provider, so the CI/CD pipeline authenticates with short-lived, federated credentials rather than embedded static tokens. This directly satisfies the requirement to use an existing external IDP without long-lived secrets.

Why this answer

Configuring the API server with --oidc-issuer-url, --oidc-client-id, and related flags lets it validate JSON Web Tokens (ID tokens) issued by an external OIDC identity provider, enabling short-lived, federated authentication for the CI/CD pipeline without static credentials. The pipeline obtains a token from the IdP (e.g., via client credentials or workload identity federation) and presents it as a Bearer token; the API server verifies the signature against the issuer's JWKS and maps claims to a username and groups for RBAC.

Exam trap

The trap is that candidates see 'external identity provider' and reach for basic auth or anonymous access as 'simple' options, missing that OIDC flags are the only mechanism that federates with an external IdP using short-lived JWTs.

How to eliminate wrong answers

Option A is wrong because storing an admin kubeconfig in a public ConfigMap exposes cluster-admin credentials to anyone who can read the ConfigMap, and ConfigMaps are not secret stores — this is a severe security anti-pattern. Option C is wrong because enabling anonymous requests (--anonymous-auth=true) grants unauthenticated access to the API server, and CIDR-based trust is spoofable and far too broad; anonymous requests should be disabled in production. Option D is wrong because --basic-auth-file uses static username/password credentials stored in a file, which are long-lived, not tied to an external IdP, and the basic auth mechanism is deprecated and disabled by default in modern Kubernetes.

Full explanation →

254

MCQmedium

A cluster administrator needs to intercept and reject any resource creation requests that do not include a mandatory security-context label. Which admission controller type should be implemented?

A.MutatingAdmissionWebhook

B.ServiceAccount

C.ValidatingAdmissionWebhook

D.NamespaceLifecycle

AnswerC

ValidatingAdmissionWebhook satisfies the requirement to reject non-compliant requests, as it evaluates objects against custom rules and denies those failing validation. Unlike mutating webhooks, which may alter requests, this controller only permits or blocks them, making it ideal for enforcing the mandatory security-context label without modifying resource definitions.

Why this answer

A ValidatingAdmissionWebhook is the correct choice because it is invoked during the admission review phase and can evaluate an incoming object against custom policy logic, returning an 'allowed: false' response to reject requests that fail validation. Since the requirement is to intercept and reject resource creation requests missing a mandatory label, a validating webhook is purpose-built for this enforcement. Mutating webhooks can only modify objects, not reject them, and built-in controllers like ServiceAccount or NamespaceLifecycle do not perform arbitrary label validation.

Exam trap

KCSA often tests the distinction between mutating and validating admission webhooks, and candidates incorrectly assume a mutating webhook can reject requests or that built-in controllers like NamespaceLifecycle can enforce custom policies.

How to eliminate wrong answers

Option A is wrong because MutatingAdmissionWebhook is designed to mutate (patch) incoming objects before persistence, not to reject them based on policy violations. Option B is wrong because ServiceAccount is a built-in admission controller that automates service account token mounting, not a mechanism for enforcing custom label requirements. Option D is wrong because NamespaceLifecycle only enforces namespace existence and prevents operations in terminating namespaces; it has no capability to validate arbitrary labels on resources.

Full explanation →

255

Multi-Selectmedium

Which TWO of the following mechanisms are standard methods used by container runtimes (such as containerd or CRI-O) to isolate container workloads from the host kernel and other containers? (Choose TWO)

Select 2 answers

A.Disabling the Linux virtual memory manager cluster-wide

B.Hypervisor-based hardware virtualization for every container instance

C.Executing all container processes inside the host root process namespace

D.Control Groups (cgroups)

E.Linux Namespaces

AnswersD, E

Control groups limit and account for CPU, memory, and I/O consumed by container processes, preventing one workload from starving the host or neighbours. This resource-isolation mechanism complements namespace isolation, satisfying the stem's requirement for standard runtime isolation methods.

Why this answer

Option D (Control Groups, cgroups) is correct because container runtimes such as containerd and CRI-O use cgroups to limit and account for resources like CPU, memory, block I/O, and PIDs, preventing one container from starving or affecting others. Option E (Linux Namespaces) is correct because runtimes use namespaces (PID, mount, network, UTS, IPC, user, cgroup) to give each container its own isolated view of processes, filesystems, networking, and other kernel resources. Together, cgroups and namespaces are the foundational Linux kernel primitives that standard container runtimes rely on for isolation.

Option A is wrong because disabling the virtual memory manager cluster-wide is neither possible nor a container isolation mechanism; it would break the host. Option B is wrong because standard runtimes like containerd and CRI-O share the host kernel and do not spin up a hypervisor per container (that describes VM-based sandboxes such as Kata Containers). Option C is wrong because running all container processes in the host root PID namespace would remove PID isolation rather than provide it.

Exam trap

KCSA often tests whether candidates confuse container isolation primitives (namespaces + cgroups) with VM-based isolation (hypervisors), so the trap is picking 'hypervisor-based virtualization' as a standard container runtime mechanism.

Full explanation →

256

MCQeasy

Which of the following describes a recommended security practice when managing Kubernetes Secrets?

A.Use ConfigMaps for passwords and Secrets for plain text configuration.

B.Store secret values in plain text inside public Git repositories for easy collaboration.

C.Limit RBAC access so that only necessary users and service accounts can read secrets.

D.Disable authentication on the Kubernetes API server to simplify secret retrieval.

AnswerC

RBAC restricts secret read verbs to specific users and service accounts, shrinking the blast radius if credentials leak. Least-privilege access directly reduces exposure of sensitive data stored in Secrets, satisfying the recommended practice of limiting who can retrieve them.

Why this answer

The recommended practice is to follow the principle of least privilege by restricting who can read Secrets. Kubernetes Secrets are not encrypted by default; they are only base64-encoded, so any user or service account with get/list/watch permissions on Secrets can easily decode and view sensitive data. Limiting RBAC access ensures that only authorized workloads and administrators can access specific Secrets, reducing the attack surface and potential for credential leakage.

Exam trap

KCSA often tests the misconception that Kubernetes Secrets are encrypted by default or that base64 encoding provides security, leading candidates to overlook the need for strict RBAC controls.

How to eliminate wrong answers

Option A is wrong because ConfigMaps are designed for non-sensitive configuration data and are stored in plain text; using them for passwords would expose credentials. Option B is wrong because storing secrets in plain text in public Git repositories is a severe security risk, as anyone can view and misuse them. Option D is wrong because disabling authentication on the Kubernetes API server would allow unauthenticated access to all resources, including Secrets, completely undermining cluster security.

Full explanation →

257

MCQmedium

Your team is storing sensitive database credentials in Kubernetes Secrets. A security review reveals that base64 encoding does not provide encryption at rest. What mechanism should you enable to ensure Secrets are encrypted when stored in etcd?

A.Apply a MutatingWebhookConfiguration to automatically hash passwords using bcrypt.

B.Enable TLS encryption for all intra-cluster communication using kubeadm configuration.

C.Configure an EncryptionConfiguration file and reference it via the '--encryption-provider-config' flag on the kube-apiserver.

D.Set the secret type to 'kubernetes.io/encrypted-secret'.

AnswerC

The EncryptionConfiguration resource defines providers (for example, aesgcm or kms) that encrypt Secret objects before they are written to etcd. Passing it via --encryption-provider-config makes the kube-apiserver perform that encryption, closing the base64 plaintext-at-rest gap.

Why this answer

To encrypt Secrets at rest in etcd, you must configure an EncryptionConfiguration file and pass it to the kube-apiserver via the --encryption-provider-config flag. This enables encryption of resources like Secrets before they are stored in etcd.

Exam trap

KCSA often tests the method to encrypt Secrets at rest, and candidates may confuse it with TLS or other encryption mechanisms.

How to eliminate wrong answers

Option A is wrong because MutatingWebhookConfiguration cannot hash passwords in Secrets; it mutates pod specs, not Secret data. Option B is wrong because TLS encryption secures data in transit, not at rest in etcd. Option D is wrong because there is no such Secret type as 'kubernetes.io/encrypted-secret'; Secret types are predefined and do not include encryption.

Full explanation →

258

MCQhard

A security engineer is configuring a service mesh using Istio to ensure that all east-west traffic between microservices is mutually authenticated and encrypted. Which custom resource must be configured with a STRICT mTLS mode to enforce this requirement cluster-wide?

A.PeerAuthentication

B.EnvoyFilter

C.AuthorizationPolicy

D.DestinationRule

AnswerA

PeerAuthentication enforces mutual TLS between sidecar proxies, and setting its mtls.mode to STRICT cluster-wide (via the mesh-wide policy in the istio-system namespace) rejects all plaintext east-west traffic. This directly satisfies the requirement that every microservice-to-microservice connection be mutually authenticated and encrypted, unlike RequestAuthentication, which only validates end-user JWTs.

Why this answer

PeerAuthentication is the Istio custom resource used to configure mTLS settings for workloads. Setting its mTLS mode to STRICT enforces mutual TLS for all traffic to and from the selected workloads, ensuring east-west traffic is authenticated and encrypted.

Exam trap

The trap is confusing PeerAuthentication with DestinationRule or AuthorizationPolicy. Candidates might think DestinationRule enforces mTLS, but it only configures outbound TLS settings; PeerAuthentication is the resource that enforces mTLS on the server side.

How to eliminate wrong answers

Option B is wrong because EnvoyFilter is used to customize the Envoy proxy configuration, not to enforce mTLS policies directly. Option C is wrong because AuthorizationPolicy controls access based on identities and conditions, but it does not enforce encryption; it assumes mTLS is already in place. Option D is wrong because DestinationRule configures traffic policies like load balancing and connection pools, and while it can specify TLS settings for outbound traffic, it does not enforce mTLS cluster-wide; PeerAuthentication is the correct resource for mTLS enforcement.

Full explanation →

259

MCQmedium

An engineer is reviewing the threat model of a Kubernetes cluster exposed to the public internet via a LoadBalancer service. Which configuration flaw most commonly leads to unintended external exposure of administrative dashboards?

A.Configuring liveness probes with HTTP GET requests instead of TCP socket checks

B.Exposing management dashboards via LoadBalancer or NodePort services without authentication or IP whitelisting

C.Setting imagePullPolicy to IfNotPresent on production deployments

D.Using ClusterIP service types for internal database connectivity

AnswerB

Publishing dashboards through LoadBalancer or NodePort services without authentication or IP whitelisting exposes them to the internet, letting anyone reach administrative interfaces. This misconfiguration, not the service type alone, is the common cause of unintended external exposure.

Why this answer

The most common cause of unintended external exposure of administrative dashboards (Kubernetes Dashboard, kube-state-metrics, Prometheus, Argo CD, etc.) is exposing them via a LoadBalancer or NodePort Service without authentication or IP whitelisting. This publishes the dashboard to the public internet, and if it lacks strong auth or has default credentials, attackers can reach it directly — this is the pattern behind many real-world Kubernetes breaches. The fix is to use ClusterIP with an authenticating ingress, or restrict access via IP allowlists and strong auth.

Exam trap

KCSA often tests whether candidates can identify the most common misconfiguration leading to external exposure — the trap is picking subtle-sounding options (probe type, imagePullPolicy) instead of the obvious but correct answer: exposing dashboards via LoadBalancer/NodePort without auth or IP whitelisting.

How to eliminate wrong answers

Option A is wrong because liveness probe type (HTTP GET vs TCP socket) affects health checking behavior, not external exposure — probes are internal kubelet checks and do not open ports to the internet. Option C is wrong because imagePullPolicy: IfNotPresent affects whether kubelet pulls an image if it already exists locally; it is a supply-chain/consistency concern, not a cause of dashboard exposure. Option D is wrong because ClusterIP is the internal-only Service type — using it for databases is a security best practice, not a flaw, and it does not expose anything externally.

Full explanation →

260

MCQeasy

Which open-source auditing tool provides compliance scores and checks against Kubernetes security frameworks such as NSA-CISA and CIS?

A.Kube-dns

B.Metric-server

C.Cilium

D.Kubescape

AnswerD

Kubescape scans Kubernetes clusters and manifests, producing compliance scores mapped to frameworks including NSA-CISA and CIS benchmarks. Its posture reports and risk scoring directly satisfy the requirement for an open-source auditing tool that grades clusters against those named security frameworks.

Why this answer

Kubescape is an open-source Kubernetes security platform that scans clusters and manifests against frameworks like NSA-CISA, MITRE ATT&CK, and CIS Benchmarks, producing compliance scores and remediation guidance. It is specifically designed for Kubernetes posture management and is widely used in CNCF-aligned environments. The other options are Kubernetes components or networking tools, not auditing/compliance scanners.

Exam trap

KCSA often tests the confusion between networking/observability tools (Cilium, Metric-server) and dedicated security posture scanners (Kubescape), leading candidates to pick a CNI tool for compliance scoring.

How to eliminate wrong answers

Option A is wrong because Kube-dns (CoreDNS) provides DNS resolution for services and pods, not security auditing or compliance scoring. Option B is wrong because Metric-server collects resource metrics for HPA and kubectl top, not security posture. Option C is wrong because Cilium is a CNI/eBPF-based networking, observability, and security tool, but it does not provide compliance scores against NSA-CISA or CIS frameworks.

Full explanation →

261

Multi-Selecthard

Which THREE of the following features or configurations are associated with securing Ingress traffic in a Kubernetes cluster? (Choose THREE)

Select 3 answers

A.Configuring TLS blocks in the Ingress resource referencing a kubernetes.io/tls Secret.

B.Directly exposing internal Pod clusterIPs to the public internet via kube-proxy bypass rules.

C.Integrating Web Application Firewall (WAF) modules or OAuth/OIDC authentication filters via Ingress annotations or middleware.

D.Removing all network policies so the Ingress controller can freely probe unmanaged host ports.

E.Using annotations to enforce HTTP-to-HTTPS redirection so unencrypted traffic is automatically upgraded.

AnswersA, C, E

TLS blocks in an Ingress reference a kubernetes.io/tls Secret holding the certificate and private key, so the ingress controller terminates HTTPS for the named hosts. This encrypts client-to-cluster traffic, satisfying the requirement to secure Ingress traffic in transit.

Why this answer

Option A is correct because a Kubernetes Ingress resource secures traffic by defining a TLS block that references a kubernetes.io/tls Secret containing the certificate and private key, enabling the Ingress controller to terminate TLS for the specified hosts. Option C is correct because Ingress controllers commonly support annotations or middleware (for example NGINX Ingress annotations or Traefik middleware) that attach WAF modules or OAuth/OIDC authentication filters to protect inbound HTTP(S) traffic before it reaches backend Services. Option E is correct because annotations such as nginx.ingress.kubernetes.io/force-ssl-redirect or ssl-redirect enforce HTTP-to-HTTPS redirection, ensuring clients are automatically upgraded to encrypted connections.

Option B is incorrect because bypassing kube-proxy to expose Pod clusterIPs directly to the internet is not a supported or secure Ingress practice and defeats the purpose of controlled ingress. Option D is incorrect because removing all NetworkPolicies weakens cluster security and is unrelated to securing Ingress traffic; NetworkPolicies govern pod-to-pod traffic, not Ingress TLS or authentication.

Exam trap

KCSA often tests the confusion between Ingress-level security controls (TLS, WAF, redirects) and Pod-level controls (network policies, security contexts) — candidates pick options that sound secure but actually weaken the cluster.

Full explanation →

262

MCQhard

You are troubleshooting a secure etcd cluster where a new control plane node cannot join the cluster. The logs indicate a TLS handshake failure between etcd peers. Which etcd configuration flag specifies the trusted CA certificate used to verify peer certificates?

A.--trusted-ca-file

B.--peer-client-cert-auth

C.--peer-trusted-ca-file

D.--etcd-ca-file

AnswerC

The `--peer-trusted-ca-file` flag loads the CA bundle that etcd uses to validate certificates presented by peer nodes during mutual TLS. Since the stem describes a peer-to-peer TLS handshake failure, this flag directly satisfies the requirement for verifying peer certificates, unlike client-facing or server certificate flags.

Why this answer

etcd uses separate TLS configurations for client-facing and peer-to-peer traffic. The --peer-trusted-ca-file flag specifies the CA bundle that etcd uses to verify the certificates presented by its peer etcd members during mutual TLS handshakes. Since the failure is a peer TLS handshake, the peer-specific CA flag is the correct one to check and configure.

Exam trap

KCSA often tests the distinction between etcd's client TLS flags and peer TLS flags, so candidates must not confuse --trusted-ca-file (client) with --peer-trusted-ca-file (peer) when the symptom is a peer handshake failure.

How to eliminate wrong answers

Option A is wrong because --trusted-ca-file applies to client-facing TLS (verifying clients connecting to etcd's client port), not to peer-to-peer member communication. Option B is wrong because --peer-client-cert-auth is a boolean that enables requiring and verifying peer client certificates; it does not itself specify which CA to trust. Option D is wrong because --etcd-ca-file is not a standard etcd flag (it resembles kube-apiserver's --etcd-cafile, which is used by the API server, not by etcd itself).

Full explanation →

263

Multi-Selectmedium

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

Select 2 answers

A.serviceSelector

B.namespaceSelector

C.ingressSelector

D.nodeSelector

E.podSelector

AnswersB, E

A namespaceSelector matches source pods by their namespace's labels, satisfying the requirement to specify allowed traffic sources in an ingress rule. It operates at namespace granularity, unlike podSelector's per-pod matching, and combines with podSelector within a single from element to permit cross-namespace traffic precisely.

Why this answer

In a Kubernetes NetworkPolicy ingress rule, the from field accepts three selector-based peer types: ipBlock, namespaceSelector, and podSelector. Option B (namespaceSelector) is correct because it selects entire namespaces by their labels, allowing traffic from all pods in matching namespaces (or, when combined with a podSelector in the same from element, only matching pods in matching namespaces). Option E (podSelector) is correct because it selects pods by their labels within the policy's own namespace, defining which pods may send traffic to the selected pods.

Option A (serviceSelector) is incorrect because NetworkPolicy peers are never defined by Service; Services are not valid peer selectors in the API. Option C (ingressSelector) is incorrect because no such selector type exists in the NetworkPolicy spec. Option D (nodeSelector) is incorrect because NetworkPolicy operates at the pod/namespace/IP level and cannot select peers by node labels.

Exam trap

KCSA often tests whether candidates confuse scheduling selectors like nodeSelector with NetworkPolicy selectors; the trap is picking nodeSelector because it sounds like a network source selector.

Full explanation →

264

MCQeasy

When configuring the Kubernetes API server authorization modes, which mode evaluates requests against Kubernetes RBAC policies?

A.RBAC

B.Webhook

C.Node

D.AlwaysAllow

AnswerA

RBAC authorises requests by evaluating them against Role and ClusterRole bindings defined in Kubernetes RBAC policies, satisfying the stem's requirement for the mode that checks RBAC rules. Enabled via the API server's authorization-mode flag, it grants permissions based on subjects, verbs, resources and namespaces.

Why this answer

The RBAC authorization mode in the Kubernetes API server evaluates requests against Role-Based Access Control policies defined via Roles, ClusterRoles, RoleBindings, and ClusterRoleBindings. When enabled, the API server checks whether the requesting user or service account has a binding that grants the required verb on the target resource. RBAC is the standard, fine-grained authorization mechanism in modern Kubernetes clusters.

Exam trap

KCSA often tests the confusion between authentication and authorization modes, or between RBAC and external policy engines like Webhook, causing candidates to select Webhook when the question specifically asks about built-in Kubernetes RBAC evaluation.

How to eliminate wrong answers

Option B (Webhook) is wrong because Webhook mode delegates authorization decisions to an external HTTP service (e.g., OPA Gatekeeper), not to Kubernetes RBAC policies. Option C (Node) is wrong because Node mode is a special-purpose authorizer for kubelet requests, granting permissions based on the node's identity — it does not evaluate RBAC policies. Option D (AlwaysAllow) is wrong because AlwaysAllow permits all requests unconditionally, bypassing any policy evaluation entirely and is only suitable for testing.

Full explanation →

265

Multi-Selecthard

An enterprise is enforcing the CIS Kubernetes Benchmark for control plane configuration. Which TWO parameters must be correctly configured on the kube-apiserver to meet strict compliance auditing standards? (Choose TWO)

Select 2 answers

A.--audit-policy-file

B.--service-account-lookup=false

C.--enable-bootstrap-auth-only=true

D.--profiling=true

E.--audit-log-path

AnswersA, E

Supplying --audit-policy-file defines the audit rules and stages the API server records, satisfying the CIS requirement for a defined audit policy. Without it, no audit events are generated, so compliance auditing cannot evidence control plane activity.

Why this answer

Option A (--audit-policy-file) is correct because the CIS Kubernetes Benchmark requires the API server to have an audit policy defined that specifies what events are recorded and at what level; without this flag the apiserver cannot apply a compliant audit policy. Option E (--audit-log-path) is correct because CIS requires audit logging to be enabled and written to a defined destination, and this flag sets the file path where audit events are persisted for compliance auditing. Option B (--service-account-lookup=false) is wrong because CIS requires service account token lookup to remain enabled (true), since disabling it weakens token validation.

Option C (--enable-bootstrap-auth-only=true) is wrong because it is not a valid kube-apiserver flag and does not correspond to any CIS control. Option D (--profiling=true) is wrong because CIS recommends disabling profiling (--profiling=false) to reduce information exposure on the control plane.

Exam trap

KCSA often tests specific kube-apiserver flags required by CIS; candidates may confuse audit-related flags with other security flags like --profiling or --service-account-lookup, which are not part of the audit requirement.

Full explanation →

266

MCQeasy

Which of the following is a key component of the Kubernetes threat model concerning the compromise of node kubelets via insecure configuration?

A.Leaving the Kubelet read-only port (10255) enabled and accessible

B.Enforcing Pod Security Admission in restricted mode

C.Using secure HTTPS client certificates for API server communication

D.Enabling RBAC authorization mode across the control plane

AnswerA

The unauthenticated read-only port 10255 exposes kubelet APIs without any authentication or authorisation, letting anyone query pod specs and node data. Leaving it enabled and reachable is the insecure configuration that enables kubelet compromise within the Kubernetes threat model.

Why this answer

The Kubelet read-only port 10255 exposes unauthenticated, unencrypted access to pod and node information (and in some configurations, more). Leaving it enabled and reachable is a well-known Kubernetes threat model item because an attacker on the network can query it to enumerate workloads, extract metadata, and potentially pivot. Hardening guidance (CIS Kubernetes Benchmark) explicitly requires disabling it via --read-only-port=0.

Exam trap

KCSA often tests whether candidates can identify insecure defaults versus security controls — the trap is picking a hardening measure (PSA, RBAC, client certs) as the 'threat' when the question asks for a vulnerability.

How to eliminate wrong answers

Option B is wrong because enforcing Pod Security Admission in restricted mode is a hardening control that reduces pod-level risk; it is not a threat vector related to kubelet compromise. Option C is wrong because using secure HTTPS client certificates for API server communication is a best practice that strengthens authentication; it is not a vulnerability. Option D is wrong because enabling RBAC authorization mode is a security control that restricts API access; it is not a kubelet misconfiguration.

Full explanation →

267

Multi-Selecthard

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

Select 3 answers

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

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

C.The pod's ServiceAccount has a ClusterRoleBinding granting cluster-admin permissions.

D.The pod is configured with hostNetwork: true, allowing it to sniff traffic on the node's network interface.

E.The cloud provider's instance metadata service is accessible without IMDSv2 token restrictions from the pod network.

AnswersC, D, E

A ClusterRoleBinding to cluster-admin grants the ServiceAccount full control over every namespace and cluster-scoped resource. Any pod using that ServiceAccount inherits those permissions, so the compromised pod can immediately read secrets, create privileged workloads and pivot cluster-wide.

Why this answer

Option C is correct because a ClusterRoleBinding that binds the pod's ServiceAccount to the cluster-admin ClusterRole grants that pod full, unrestricted permissions across every namespace and resource in the cluster, so a compromised pod can immediately read secrets, create privileged workloads, and take over the control plane. Option D is correct because hostNetwork: true places the pod in the node's network namespace, letting the attacker sniff node-level traffic (including kubelet, API server, and other pods' unencrypted communications) and reach services bound to the node's interfaces, which materially aids lateral movement. Option E is correct because if the instance metadata service (169.254.169.254) is reachable without IMDSv2 session-token enforcement, a compromised pod can retrieve the node's IAM credentials and use them against the cloud API, pivoting from the cluster into the underlying cloud infrastructure.

Option A does not belong because KMS-backed etcd encryption at rest protects data on disk and does nothing to help an attacker already executing inside a pod. Option B does not belong because the Restricted Pod Security Standard blocks privileged settings such as hostNetwork and hostPath, so it actually hinders rather than aids escalation.

Exam trap

KCSA often tests the confusion between controls that harden the cluster (encryption, PSS) and misconfigurations that enable attacker movement (over-permissive RBAC, hostNetwork, open IMDS).

Full explanation →

268

MCQeasy

Which component provides network routing and iptables/IPVS rule management across worker nodes for Kubernetes Services?

A.kube-scheduler

B.kube-apiserver

C.etcd

D.kube-proxy

AnswerD

kube-proxy runs on every worker node and programs iptables or IPVS rules to implement Service virtual IPs and load balancing. This satisfies the stem's routing and rule-management requirement, since kube-proxy is the component translating Service definitions into node-level packet-forwarding rules.

Why this answer

kube-proxy runs on every node and is responsible for programming iptables (or IPVS, or nftables in newer versions) rules that implement Kubernetes Service virtual IPs and load balancing to backend pods. It watches the API server for Service and EndpointSlice objects and translates them into node-local dataplane rules. Without kube-proxy (or a replacement like Cilium's kube-proxy replacement), ClusterIP and NodePort services would not function.

Exam trap

The trap is assuming the control plane (kube-apiserver, scheduler, etcd) handles Service networking; candidates must remember kube-proxy is a per-node dataplane agent, not a control-plane service.

How to eliminate wrong answers

Option A is wrong because kube-scheduler only decides which node a pod should run on; it does not touch network dataplane rules. Option B is wrong because kube-apiserver is the control-plane REST endpoint that stores and serves object state, not a dataplane component. Option C is wrong because etcd is the distributed key-value store backing the cluster state; it has no role in routing or iptables/IPVS programming.

Full explanation →

269

MCQmedium

A security team discovers that an application container running as root has successfully mounted the host's Docker socket (`/var/run/docker.sock`). What is the primary attack vector enabled by this misconfiguration?

A.Bypassing Kubernetes NetworkPolicies across different worker nodes

B.Direct modification of the etcd database state via local unix socket tunneling

C.Container escape and full node takeover by orchestrating new sibling containers with host mounts

D.Automatic escalation of RBAC roles assigned to the API server

AnswerC

Mounting the Docker socket grants the container control over the host's Docker daemon, enabling creation of sibling containers with host filesystem mounts. This escapes the container boundary and achieves full node takeover, directly satisfying the stem's root-container-with-socket constraint.

Why this answer

Mounting the host's Docker socket into a container gives that container full control over the Docker daemon, which runs as root on the host. An attacker can use the Docker API to start a new privileged container with the host filesystem mounted (e.g., -v /:/host), then chroot into it to gain root on the node — a classic container escape. This is the primary attack vector: full node takeover, and potentially lateral movement to other nodes via the cluster network or credentials.

Exam trap

KCSA often tests container escape vectors by presenting a mounted Docker socket and expecting candidates to recognize node takeover, while distracting with plausible but incorrect options about NetworkPolicies, etcd, or RBAC escalation.

How to eliminate wrong answers

Option A is wrong because NetworkPolicies are enforced by CNI plugins at the network layer; Docker socket access does not bypass them — the attacker would still be subject to network policy for pod-to-pod traffic. Option B is wrong because etcd is not accessible via a local Unix socket from the Docker socket; etcd listens on its own ports (2379/2380) and requires client certs, and the Docker socket does not tunnel to etcd. Option D is wrong because RBAC roles are managed by the Kubernetes API server, not the Docker daemon; Docker socket access does not automatically escalate Kubernetes RBAC permissions.

Full explanation →

270

Multi-Selecthard

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

Select 3 answers

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

B.Container image signing with Cosign and admission verification for Container

C.Kubernetes NetworkPolicies for microservice isolation in the Cluster

D.Granting all developers cluster-admin permissions for operational speed

E.Static Application Security Testing (SAST) scanning in the CI/CD pipeline for Code

AnswersB, C, E

Cosign signing plus admission verification enforces supply-chain integrity at the Container layer, blocking unsigned or tampered images before they run. This gives an independent control at a distinct 4Cs layer, satisfying the stem's defence-in-depth requirement.

Why this answer

Option B is correct because container image signing with Cosign plus an admission controller that verifies signatures enforces supply-chain integrity at the Container layer, ensuring only trusted, unmodified images are admitted to the cluster. Option C is correct because Kubernetes NetworkPolicies provide Cluster-layer microsegmentation, restricting pod-to-pod traffic to explicitly allowed flows and limiting lateral movement if a workload is compromised. Option E is correct because SAST scanning in the CI/CD pipeline addresses the Code layer, detecting insecure code patterns and vulnerabilities before artifacts are built or deployed.

Option A is not a valid independent control since relying solely on a cloud provider's default network security group creates a single point of failure and violates defense-in-depth. Option D is not a security control at all; granting all developers cluster-admin permissions violates least privilege and dramatically expands the attack surface.

Exam trap

The trap is selecting options that sound security-related but actually weaken posture (cluster-admin for all, single default control) — candidates must recognise that defense-in-depth requires independent, layered controls, not convenience shortcuts.

Full explanation →

271

MCQeasy

What is the primary security benefit of using immutable container base distroless images?

A.They prevent the API server from restarting during control plane upgrades.

B.They automatically encrypt persistent storage volumes attached to the pod.

C.They eliminate unnecessary shells and package managers, drastically reducing the attack surface.

D.They configure automatic mTLS between all pods in the cluster via CNI.

AnswerC

Distroless images ship only the application and its runtime dependencies, omitting shells, package managers and other utilities. Removing these executables denies attackers post-exploitation tooling and reduces exploitable packages, directly shrinking the attack surface as the scenario requires.

Why this answer

Distroless images contain only the application and its runtime dependencies, omitting package managers, shells, and other utilities. This drastically reduces the attack surface because attackers cannot easily execute shell commands, install tools, or exploit vulnerabilities in unnecessary packages. The primary security benefit is the minimized attack surface.

Exam trap

The trap is attributing unrelated security benefits to distroless images, such as encryption or mTLS; candidates must remember that distroless primarily reduces attack surface by removing unnecessary components.

How to eliminate wrong answers

Option A is wrong because distroless images have no impact on API server restarts during control plane upgrades; that is a control plane concern. Option B is wrong because distroless images do not encrypt persistent storage volumes; encryption is handled by storage classes or CSI drivers. Option D is wrong because distroless images do not configure mTLS between pods; mTLS is provided by a service mesh or CNI plugin, not by the image itself.

Full explanation →

272

Multi-Selectmedium

An organization is performing a STRIDE-based threat model on their Kubernetes deployment. Which TWO of the following threats map directly to the 'Tampering' category in a Kubernetes environment?

Select 2 answers

A.An attacker altering container image layers stored in an insecure registry

B.An attacker modifying Kubernetes API objects stored directly or in transit via compromised credentials

C.An attacker flooding the API server with requests to exhaust control plane memory

D.An attacker sniffing unencrypted pod-to-pod network traffic across the CNI bridge

E.An administrator denying that they executed a cluster deletion command due to missing logs

AnswersA, B

Tampering covers unauthorised modification of data. Altering image layers in a registry modifies stored artefacts, corrupting the integrity of what clusters pull and run. This directly satisfies the stem by mapping an integrity-violation scenario to the Tampering category.

Why this answer

Option A is correct because Tampering in STRIDE covers unauthorized modification of data, and altering container image layers in an insecure registry is a direct integrity attack on stored artifacts that Kubernetes nodes later pull and run. Option B is correct because modifying Kubernetes API objects—whether at rest in etcd or in transit to the API server using compromised credentials—is unauthorized alteration of cluster configuration and state, which is the canonical Tampering threat in Kubernetes. Option C is not Tampering but Denial of Service, since flooding the API server to exhaust control plane memory targets availability rather than integrity.

Option D is Information Disclosure (sniffing unencrypted pod-to-pod traffic), not Tampering, because it involves reading data rather than modifying it. Option E is Repudiation, as it concerns an administrator denying an action due to missing logs, which maps to the non-repudiation property rather than integrity.

Exam trap

The trap is conflating all 'attacker does something bad' scenarios with Tampering — candidates must distinguish integrity violations (Tampering) from confidentiality (Information Disclosure), availability (DoS), and accountability (Repudiation) violations.

Full explanation →

273

Multi-Selecthard

Which THREE practices are critical for securing container registries and image distribution pipelines? (Choose three)

Select 3 answers

A.Enabling automated vulnerability scanning upon image push

B.Enforcing role-based access control (RBAC) on registry repositories

C.Storing registry admin credentials in plaintext inside Dockerfiles

D.Allowing anonymous write access to public repositories

E.Using image signing and verification (e.g., Notary or Cosign) to guarantee artifact integrity

AnswersA, B, E

Automated vulnerability scanning on push inspects image layers against known CVE databases immediately, blocking flawed artefacts before they reach production. This satisfies the stem's requirement by securing the distribution pipeline at the earliest registry ingestion point.

Why this answer

Option A is correct because automated vulnerability scanning on image push (e.g., via Trivy, Clair, or registry-native scanners like Amazon ECR or Harbor) detects known CVEs in base images and dependencies before vulnerable artifacts propagate through the pipeline. Option B is correct because enforcing RBAC on registry repositories ensures least-privilege access, so only authorized identities can push, pull, or delete specific images, preventing unauthorized tampering or exfiltration. Option E is correct because image signing and verification with Notary or Cosign (using the OCI signature spec and tools like cosign verify) cryptographically guarantees artifact integrity and provenance, blocking tampered or untrusted images from being deployed.

Option C is wrong because embedding admin credentials in plaintext Dockerfiles exposes secrets in image layers and version control, violating secret-management best practices. Option D is wrong because anonymous write access to public repositories allows anyone to push malicious images, enabling supply-chain attacks and image poisoning.

Exam trap

The trap is selecting obviously insecure options (plaintext credentials, anonymous write access) as if they were security practices, when the question asks for critical practices — candidates must recognize these as anti-patterns.

Full explanation →

274

MCQmedium

Your security team has discovered that an application container image contains outdated packages with known remote code execution vulnerabilities. Which phase of the software development lifecycle is the most effective place to initially scan and remediate these vulnerabilities?

A.Node OS package manager updates

B.Kubelet container startup phase

C.CI/CD pipeline build stage

D.Kubernetes API server audit logging

AnswerC

Scanning at the CI/CD build stage catches vulnerable packages before the image is published, so remediation happens once rather than per deployment. This satisfies the requirement to fix outdated packages at the earliest effective point in the lifecycle.

Why this answer

Scanning in the CI/CD pipeline build stage catches vulnerable packages before the image is pushed to a registry or deployed, enabling remediation at the earliest point where the development team can act. This shifts security left, prevents vulnerable artifacts from propagating, and integrates with build gates that fail the pipeline on critical CVEs. Tools like Trivy, Clair, or Snyk run here.

Exam trap

KCSA often tests the misconception that runtime scanning (kubelet startup) or host patching is the 'most effective' place; the exam expects shift-left reasoning, making the CI/CD build stage the correct answer.

How to eliminate wrong answers

Option A is wrong because node OS package manager updates address host-level packages, not application container image contents, and occur after the image is already built. Option B is wrong because kubelet container startup is a runtime phase where scanning would block or delay deployment but not prevent the vulnerable image from being stored and potentially used elsewhere. Option D is wrong because API server audit logging records actions for compliance/forensics and does not scan or remediate image vulnerabilities.

Full explanation →

275

MCQhard

An auditor reviews container runtime configurations for compliance with NIST SP 800-190 recommendations on privilege escalation. Which Kubernetes feature controls whether a process can gain more privileges than its parent process?

A.allowPrivilegeEscalation: false

B.automountServiceAccountToken: false

C.runAsUser: 1000

D.privileged: false

AnswerA

Setting allowPrivilegeEscalation to false in the container's security context applies the no_new_privs kernel flag, preventing processes from gaining more privileges than their parent, such as via setuid binaries. This directly satisfies NIST SP 800-190's privilege-escalation control.

Why this answer

allowPrivilegeEscalation: false is the Kubernetes SecurityContext field that directly controls whether a process can gain more privileges than its parent process, aligning with NIST SP 800-190 guidance on preventing privilege escalation. When set to false, it sets the kernel's no_new_privs flag on the container process, blocking setuid/setgid binaries and file capabilities from elevating privileges. This is the precise control the auditor is looking for.

Exam trap

The trap is confusing related SecurityContext fields — candidates may pick runAsUser or privileged: false because they sound like privilege controls, but only allowPrivilegeEscalation: false specifically addresses a process gaining more privileges than its parent, which is the exact NIST SP 800-190 wording.

How to eliminate wrong answers

Option B is wrong because automountServiceAccountToken: false controls whether the ServiceAccount token is mounted into the Pod — it is about credential exposure, not process privilege escalation. Option C is wrong because runAsUser: 1000 sets the UID the container process runs as, which reduces privilege but does not prevent a setuid binary from escalating to root — it is a related but distinct control. Option D is wrong because privileged: false (the default) disables privileged mode (which would grant all capabilities and host device access), but it does not set no_new_privs and therefore does not block setuid-based escalation.

Full explanation →

276

Multi-Selectmedium

Which THREE of the following steps are part of proper Kubernetes control plane certificate management? (Choose THREE)

Select 3 answers

A.Using a trusted Certificate Authority (CA) rather than self-signed certificates where possible.

B.Implementing regular certificate rotation before expiration.

C.Disabling TLS verification for all internal cluster components.

D.Securing private keys with strict file permissions (e.g., 600) on control plane nodes.

E.Storing all private keys in unencrypted public ConfigMaps.

AnswersA, B, D

Using a trusted Certificate Authority ensures control plane components validate each other through a shared trust anchor, rather than relying on self-signed certificates that complicate rotation and revocation. This satisfies the stem's requirement for proper certificate management by establishing verifiable identity across the API server, controller manager, and scheduler, reducing the risk of impersonation within the cluster.

Why this answer

Option A is correct because using a trusted Certificate Authority (CA) instead of self-signed certificates provides a verifiable chain of trust for control plane components such as kube-apiserver, kube-controller-manager, and kube-scheduler, reducing the risk of man-in-the-middle attacks. Option B is correct because Kubernetes control plane certificates have finite validity periods (commonly one year for kubeadm-managed clusters), and regular rotation before expiration—via commands like kubeadm certs renew or automated rotation—prevents cluster outages and API server unavailability. Option D is correct because private keys for control plane components must be protected with strict file permissions such as 600 (read/write only by owner) to prevent unauthorized access, which is a standard hardening practice for files like /etc/kubernetes/pki/apiserver.key.

Option C is not correct because disabling TLS verification for internal cluster components removes authentication and encryption guarantees, exposing the control plane to interception and spoofing rather than being a proper certificate management step. Option E is not correct because storing private keys in unencrypted public ConfigMaps exposes them to any user or process with read access to the API, violating key confidentiality and Kubernetes security best practices.

Exam trap

KCSA often tests whether candidates can spot security anti-patterns disguised as 'management' steps — the trap is selecting options that sound like certificate handling but actually weaken TLS or expose keys.

Full explanation →

277

MCQmedium

An administrator suspects that someone is attempting brute-force attacks against the Kubernetes API server. Where should the administrator look to inspect authentication failures generated by the API server?

A.The etcd WAL (Write-Ahead Log) files.

B.The kubelet container logs on worker nodes.

C.The kube-proxy packet capture logs.

D.API server audit logs configured via --audit-log-path.

AnswerD

Audit logging records every request to the API server, including authentication failures with source IP, user and response status. Configuring --audit-log-path writes these events to disk, giving the administrator the forensic trail needed to identify brute-force attempts against the API server.

Why this answer

The kube-apiserver audit log, enabled with flags like --audit-log-path, --audit-policy-file, and --audit-log-maxage, records every request including authentication failures, the requesting user, source IP, and response status. Brute-force attempts appear as repeated 401 Unauthorized responses from the same source, making the audit log the authoritative source for this investigation.

Exam trap

KCSA often tests the misconception that etcd logs or kubelet logs contain API authentication events, when only the API server audit log records them.

How to eliminate wrong answers

Option A is wrong because etcd WAL files contain the Raft log of key-value operations, not API authentication events; they are for etcd recovery, not security auditing. Option B is wrong because kubelet logs on worker nodes record container runtime and pod lifecycle events, not API server authentication attempts. Option C is wrong because kube-proxy does not produce packet capture logs; it manages iptables/IPVS rules for service routing.

Full explanation →

278

MCQhard

A security engineer must ensure that a Deployment's pods always run with a read-only root filesystem, drop all Linux capabilities, and are prevented from running as root, without modifying the application's container image or Dockerfile. Which Kubernetes-native mechanism should the engineer use?

A.Create a ValidatingAdmissionPolicy that rejects any pod without the desired security settings.

B.Configure a seccomp profile of type `RuntimeDefault` on the pod and rely on it to drop capabilities and enforce a read-only root filesystem.

C.Apply a PodSecurityPolicy with `readOnlyRootFilesystem: true`, `requiredDropCapabilities: ["ALL"]`, and `runAsNonRoot: true`.

D.Set `securityContext.readOnlyRootFilesystem`, `securityContext.capabilities.drop: ["ALL"]`, and `securityContext.runAsNonRoot: true` in the pod template of the Deployment.

AnswerD

These fields in the pod template's securityContext are applied by the kubelet when starting the container, so they take effect without changing the image. `readOnlyRootFilesystem` mounts the root filesystem read-only, dropping ALL capabilities removes privileged kernel operations, and `runAsNonRoot` forces the kubelet to reject images whose user is root. This meets all three requirements natively.

Why this answer

The pod-level securityContext is the correct native control because the kubelet translates these fields into container runtime settings at start time, achieving read-only root filesystem, capability removal, and non-root execution without rebuilding the image. PodSecurityPolicy is removed, ValidatingAdmissionPolicy only denies rather than mutates, and seccomp governs syscalls, not filesystem or capability state.

Exam trap

The trap here is treating seccomp or admission validation as if it could enforce filesystem and capability restrictions that only the container securityContext actually applies.

Full explanation →

279

Multi-Selecthard

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

Select 3 answers

A.Verifying cryptographic image signatures using tools like Cosign

B.Requiring container images to be pulled exclusively from approved enterprise registries

C.Automatically updating kernel modules on the underlying worker node

D.Manually restarting unhealthy pods across worker nodes

E.Blocking deployments of images that contain unmitigated high-severity vulnerabilities

AnswersA, B, E

Admission webhooks evaluate pod specs before persistence, so they can verify Cosign signatures against a trusted public key and reject unsigned or tampered images. This enforces cryptographic provenance at admission time, satisfying the image-signature verification control.

Why this answer

Admission webhook policy engines such as Kyverno and OPA Gatekeeper intercept Kubernetes API admission requests and can validate container image attributes before a workload is persisted. Option A is correct because policies can invoke signature verification (e.g., Cosign keyless or key-based attestations) and reject pods whose images lack a valid cryptographic signature. Option B is correct because these engines can enforce registry allow-lists, rejecting any image reference whose registry does not match the approved enterprise registries.

Option E is correct because policies can query vulnerability scan results (e.g., from Trivy or Grype reports) and block deployment of images containing unmitigated high-severity CVEs. Option C is not applicable because admission webhooks only validate Kubernetes API objects; they cannot modify kernel modules on worker nodes. Option D is likewise outside their scope, since restarting unhealthy pods is a runtime remediation handled by controllers like the kubelet or ReplicaSet, not by an admission policy.

Exam trap

The trap is assuming admission webhooks can perform node-level or runtime actions (like kernel updates or pod restarts) when they only enforce policies on API objects at admission time.

Full explanation →

280

MCQmedium

You are reviewing a security alert indicating that a container running in your Kubernetes cluster attempted to modify host kernel parameters via /proc/sys. Which security configuration was likely missing or misconfigured for this container?

A.The CoreDNS deployment had too few replicas

B.The Ingress controller did not enable TLS termination

C.The PersistentVolumeClaim lacked a storage class

D.The container was run in privileged mode or lacked necessary capability and filesystem hardening

AnswerD

Writing to /proc/sys requires privileged mode or granted CAP_SYS_ADMIN plus a writable proc filesystem. Dropping capabilities, enforcing a read-only root filesystem and applying Pod Security Admission would have blocked the sysctl modification, so hardening was missing.

Why this answer

Modifying host kernel parameters via /proc/sys requires write access to the host's sysctl interface, which is only possible if the container is running in privileged mode or has been granted dangerous capabilities (e.g., CAP_SYS_ADMIN) and lacks filesystem hardening such as a read-only /proc/sys mount or seccomp/AppArmor restrictions. A properly hardened container using Pod Security Standards (restricted) or a securityContext with readOnlyRootFilesystem, dropped capabilities, and no privileged flag would block this.

Exam trap

KCSA often tests whether candidates can map a runtime symptom (host kernel modification) to the correct securityContext misconfiguration — distractors pull toward unrelated Kubernetes components (CoreDNS, Ingress, PVC) to test whether you understand the container isolation model.

How to eliminate wrong answers

Option A is wrong because CoreDNS replica count affects DNS availability and resilience, not a container's ability to write to host kernel parameters — it is unrelated to the alert. Option B is wrong because Ingress TLS termination is about encrypting external traffic to services; it has no bearing on whether a container can modify /proc/sys. Option C is wrong because a missing StorageClass affects PersistentVolumeClaim binding and storage provisioning, not kernel parameter access — it is a storage-layer misconfiguration, not a security-context one.

Full explanation →

281

MCQmedium

A cluster administrator wants to mitigate supply chain risks stemming from vulnerable base images used by developers. Where in the software lifecycle should vulnerability scanning ideally be integrated first to shift-left security?

A.Manual inspection of etcd database backups

B.Configuring kube-dns forwarding rules to external resolvers

C.Setting up PersistentVolume backup retention policies

D.CI/CD pipeline build and image registry push stages

AnswerD

Integrating scanning at the CI/CD build and registry push stages catches vulnerable base images before deployment, satisfying the shift-left constraint. This prevents flawed images entering the registry, unlike runtime scanning which detects issues only after workloads are already running.

Why this answer

Shifting left means integrating security controls as early as possible in the software development lifecycle. Scanning base images during CI/CD build and at image registry push catches vulnerable packages before they are ever deployed to the cluster, allowing developers to remediate at the source. This is the earliest practical point where image vulnerabilities can be detected and blocked.

Exam trap

KCSA often tests whether candidates recognize 'shift-left' as meaning the earliest lifecycle stage, luring them toward cluster-side or runtime controls (NetworkPolicy, PSS, etcd hardening) that are not the first integration point for image scanning.

How to eliminate wrong answers

Option A (Manual inspection of etcd database backups) is wrong because etcd backups contain cluster state, not container image contents, and manual inspection is neither shift-left nor a vulnerability scanning mechanism. Option B (Configuring kube-dns forwarding rules to external resolvers) is wrong because DNS forwarding is a name-resolution configuration unrelated to image vulnerability scanning and may itself introduce security risk. Option C (Setting up PersistentVolume backup retention policies) is wrong because PV retention governs data durability, not the detection of vulnerable base images in the supply chain.

Full explanation →

282

MCQmedium

An organization uses AWS IAM to restrict access to their EKS cluster control plane endpoints. According to the shared responsibility model, configuring and maintaining these access entries and cluster RBAC roles is the responsibility of whom?

A.The Linux kernel maintainers

B.The cloud provider only

C.The CNCF security committee

D.The customer

AnswerD

AWS secures the managed control plane infrastructure, but access entries and Kubernetes RBAC roles governing who may reach that endpoint are customer-configured identity controls. The customer therefore owns this configuration under the shared responsibility model.

Why this answer

Under the AWS shared responsibility model, AWS is responsible for security 'of' the cloud (the infrastructure), while the customer is responsible for security 'in' the cloud. For EKS, the control plane infrastructure is managed by AWS, but configuring IAM access entries and Kubernetes RBAC roles that govern who can access the cluster is a customer responsibility.

Exam trap

KCSA often tests the misconception that the cloud provider manages all aspects of a managed Kubernetes service; candidates must remember that identity and access configurations remain the customer's responsibility under the shared responsibility model.

How to eliminate wrong answers

Option A is wrong because Linux kernel maintainers are not a party in the AWS shared responsibility model; they maintain the upstream kernel, not customer-specific access controls. Option B is wrong because the cloud provider only secures the managed infrastructure, not the customer's identity and access configurations. Option C is wrong because the CNCF security committee is a standards body, not an operational entity responsible for a customer's EKS cluster.

Full explanation →

283

MCQmedium

An auditor notices that a secret is mounted as a volume in a pod. Where is this secret stored on the worker node filesystem by default?

A.In an encrypted SQLite database on the node's root partition.

B.In plaintext files inside /etc/kubernetes/secrets on the node's hard drive.

C.Inside the container image layer cache.

D.In tmpfs (memory), ensuring it is not written to non-volatile disk storage.

AnswerD

Kubernetes mounts secrets as tmpfs volumes, a memory-backed filesystem, so the data never touches the node's non-volatile disk. This satisfies the auditor's concern about persistent storage exposure: the secret exists only in RAM and is erased when the pod terminates.

Why this answer

When a secret is mounted as a volume in a pod, the kubelet writes the secret data to a tmpfs (memory-backed) filesystem on the worker node. This ensures the secret is not persisted to non-volatile disk storage by default, reducing the risk of forensic recovery from node disks. The files exist only in RAM and are removed when the pod is deleted.

Exam trap

KCSA often tests the misconception that mounted secrets are written to disk in plaintext; candidates forget that Kubernetes uses tmpfs for secret volumes by default.

How to eliminate wrong answers

Option A is wrong because Kubernetes does not store mounted secrets in an encrypted SQLite database on the node; etcd stores secrets, but the node filesystem mount is tmpfs. Option B is wrong because secrets are not written to /etc/kubernetes/secrets in plaintext on the node's hard drive; that path is not the default mount location and would violate the memory-backed design. Option C is wrong because secrets are not baked into container image layers; image layers are immutable and shared, and secrets are injected at runtime.

Full explanation →

284

MCQmedium

You have deployed a NetworkPolicy in a namespace that selects backend pods, defining an 'ingress' rule with a 'from' block. No other NetworkPolicies exist in the namespace. What is the default behavior for traffic from pods not matched by the 'from' selector?

A.All ingress traffic remains allowed by default.

B.The policy fails to apply because an egress rule must also be defined.

C.Only traffic from other namespaces is denied; same-namespace traffic is still allowed.

D.All ingress traffic from unmatched pods is denied.

AnswerD

Once a NetworkPolicy selects a pod for ingress, that pod becomes isolated, so only traffic matching a 'from' selector is permitted. Connections from unmatched pods are therefore denied by default, even though no other policies exist.

Why this answer

When a NetworkPolicy selects a pod and defines an ingress rule with a 'from' block, it becomes an allow-list for that pod's ingress traffic. Any traffic not explicitly allowed by the 'from' selector is denied by default. This is the fundamental behavior of Kubernetes NetworkPolicy: once a pod is selected by a policy, all traffic not matching the allowed rules is blocked.

Exam trap

KCSA often tests the default-deny behavior of NetworkPolicy, and candidates may incorrectly assume that only traffic from other namespaces is blocked or that same-namespace traffic remains allowed.

How to eliminate wrong answers

Option A is wrong because once a pod is selected by a NetworkPolicy, the default becomes deny for traffic not explicitly allowed; it is not allowed by default. Option B is wrong because a NetworkPolicy does not require an egress rule to be defined; ingress and egress rules are independent, and a policy can specify only ingress. Option C is wrong because NetworkPolicy does not differentiate between same-namespace and other-namespace traffic by default; all traffic not matching the 'from' selector is denied, regardless of namespace.

Full explanation →

285

Multi-Selecthard

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

Select 3 answers

A.ValidatingAdmissionWebhook

B.PodSecurity

C.InsecureServing

D.NodeRestriction

E.AlwaysAllow

AnswersA, B, D

ValidatingAdmissionWebhook calls an external HTTPS service to evaluate custom policies against incoming API requests, rejecting non-compliant objects before persistence. It satisfies the auditor's requirement for policy enforcement at admission time, enabling arbitrary organisational controls beyond built-in plugins.

Why this answer

ValidatingAdmissionWebhook (A) is correct because it lets the API server call external webhook endpoints to validate requests against custom security policies before persistence, enabling enforcement of organization-specific compliance rules. PodSecurity (B) is correct because it enforces the Pod Security Standards (privileged, baseline, restricted) at the namespace level via admission, blocking pods that violate the configured security profile. NodeRestriction (D) is correct because it is an admission plugin that limits kubelet credentials so a node can only modify its own Node object and Pods bound to it, preventing a compromised node from escalating cluster-wide.

InsecureServing (C) is not an admission plugin but a deprecated API server serving option for unauthenticated/insecure port access, and AlwaysAllow (E) is an authorization mode that permits all requests, so neither enforces security policy at admission time.

Exam trap

KCSA often tests the distinction between admission plugins (ValidatingAdmissionWebhook, PodSecurity, NodeRestriction) and authorization modes or deprecated flags (AlwaysAllow, InsecureServing) — candidates who do not know the exact plugin names pick the plausible-sounding distractors.

Full explanation →

286

Multi-Selecthard

Which THREE of the following supply chain vulnerabilities or risks can impact Kubernetes application deployments during the build or deployment phase?

Select 3 answers

A.Enforcing Pod Security Standards in baseline mode in production namespaces

B.Using outdated container base images containing known remote code execution CVEs

C.Typosquatting malicious packages in public package registries (npm, PyPI)

D.Deploying third-party Helm charts that contain backdoored deployment templates

E.Enabling Kubernetes audit logging with webhook sinks

AnswersB, C, D

Outdated base images ship known remote code execution CVEs that persist into every built layer, so exploitation occurs at runtime without any attacker action during build. This is a build-phase supply chain risk because the vulnerable dependency enters the artefact before deployment.

Why this answer

Option B is correct because outdated base images carry known RCE CVEs that are inherited by every image built FROM them, so the vulnerability is baked into the artifact during the build phase and shipped to the cluster at deployment. Option C is correct because typosquatting attacks publish malicious packages with names resembling legitimate ones on npm/PyPI, so a mistyped dependency in a Dockerfile or build script executes attacker code during image build. Option D is correct because third-party Helm charts can embed backdoored templates (e.g., privileged pods, hostPath mounts, or extra initContainers) that are rendered and applied at deployment time, compromising the workload.

Option A is not a vulnerability but a hardening control that restricts pod privileges, and Option E is a detection/auditing control using webhook sinks, so neither introduces a build- or deployment-phase supply chain risk.

Exam trap

KCSA often tests the confusion between supply chain risks and runtime/detection controls — candidates pick hardening or logging options that are mitigations, not vulnerabilities.

Full explanation →

287

Multi-Selecthard

Which THREE of the following auditing or logging mechanisms should be configured on a secure Kubernetes control plane? (Choose THREE)

Select 3 answers

A.Kubernetes API server audit logging configured with an audit policy file.

B.Routing all cluster traffic through an unencrypted proxy log.

C.Kubelet system and container execution logs on worker nodes.

D.Disabling all log outputs to prevent disk space exhaustion.

E.Etcd audit and operational logging for database transactions and peer health.

AnswersA, C, E

The API server is the single entry point for all cluster requests, so audit logging with a policy file records who did what, when and from where. This satisfies the control-plane auditing requirement by capturing authentication, authorisation and resource-modification events for later forensic review.

Why this answer

Option A is correct because the Kubernetes API server audit logging, driven by an audit policy file (--audit-policy-file), records who did what, when, and where against the API server, which is essential for detecting unauthorized or anomalous control-plane actions. Option C is correct because kubelet system and container execution logs on worker nodes capture pod lifecycle events, container runtime activity, and node-level failures, providing the workload-side visibility needed to correlate with control-plane audit events. Option E is correct because etcd audit and operational logging records database transactions and peer health, which is critical since etcd stores all cluster state and secrets, and its integrity and quorum health directly determine control-plane security and availability.

Option B is not appropriate because routing all cluster traffic through an unencrypted proxy log exposes sensitive data and violates the requirement for encrypted, integrity-protected control-plane communications. Option D is not appropriate because disabling all log outputs destroys the audit trail and violates compliance and forensic requirements; disk exhaustion should instead be managed with log rotation, retention policies, and monitoring.

Exam trap

KCSA often tests whether candidates understand that security logging must be enabled across all control-plane components, so distractors that suggest disabling logs or using unencrypted proxies tempt candidates who prioritize performance over security.

Full explanation →

288

MCQmedium

A security team needs to ensure that Kubernetes nodes have secure file permissions for the kubelet configuration files, in alignment with CIS benchmarks. What should the file permissions on "/etc/kubernetes/kubelet.conf" typically be set to?

A.777

B.755

C.600

D.644

AnswerC

CIS benchmarks require kubelet configuration files to be readable and writable only by their owner, with no group or other access. Mode 600 enforces this, preventing unprivileged users from reading credentials or settings that could be used to compromise the node.

Why this answer

CIS Kubernetes Benchmark control 4.1.1 requires that kubelet configuration files such as /etc/kubernetes/kubelet.conf be owned by root:root and have permissions of 600 or more restrictive. The 600 permission means only the owner (root) can read and write the file, preventing non-privileged users from reading the kubelet's credentials — which include the client certificate and key used to authenticate to the API server. If these files were world-readable, any local user could impersonate the kubelet and potentially escalate privileges within the cluster.

Exam trap

KCSA often tests whether candidates confuse 'readable by root only' (600) with 'readable by all but writable by root' (644) — the trap is picking 644 because it sounds restrictive, when in fact it exposes credential material to any local user.

How to eliminate wrong answers

Option A (777) is wrong because it grants read, write, and execute to owner, group, and others — the most permissive setting possible, allowing any user to modify the kubelet config and inject malicious settings. Option B (755) is wrong because while it restricts write access to the owner, it still allows group and others to read the file, exposing the kubelet's client certificate and key material to any local user. Option D (644) is wrong because it allows all users to read the file (world-readable), which leaks the kubelet's credentials even though write is restricted to root — CIS explicitly requires 600 or stricter.

Full explanation →

289

MCQhard

You are auditing a Kubernetes cluster and notice that a specific ServiceAccount has been granted the 'impersonate' verb on users. What security risk does this permission introduce?

A.It automatically generates valid X.509 client certificates for cluster nodes.

B.It allows the pod to intercept network traffic of other pods on the same node.

C.It permits the ServiceAccount to bypass the Kubernetes API server and write directly to etcd.

D.It allows the ServiceAccount to act as any user or service account, leading to privilege escalation.

AnswerD

The `impersonate` verb lets a ServiceAccount assume another identity's privileges via the Kubernetes API, bypassing its own RBAC restrictions. Granting it on users enables full privilege escalation, since the account can act as any user or service account — directly satisfying the risk described in the stem.

Why this answer

The 'impersonate' verb on users (or groups/serviceaccounts) allows the holder to send API requests with an Impersonate-User header, causing the API server to evaluate the request as that user. This effectively lets the ServiceAccount assume any identity in the cluster, including cluster-admin, enabling full privilege escalation.

Exam trap

The trap is assuming impersonate is a benign read-only permission — candidates underestimate that it grants full identity assumption and therefore privilege escalation to any role in the cluster.

How to eliminate wrong answers

Option A is wrong because X.509 client certificate generation is performed by the kube-controller-manager's CSR signing controller (or manually via openssl/cfssl), not by the impersonate verb. Option B is wrong because pod network traffic interception is a function of the CNI plugin or a privileged pod with CAP_NET_RAW/CAP_NET_ADMIN — impersonation is an API-server authorization concept. Option C is wrong because nothing bypasses the API server to write to etcd directly; etcd access requires client certificates and is a separate attack path entirely.

Full explanation →

290

Multi-Selecteasy

Which TWO configuration practices improve container runtime security on Kubernetes nodes? (Choose two)

Select 2 answers

A.Enforcing non-root execution via container securityContext

B.Mounting the Docker socket inside application containers

C.Using read-only root filesystems to prevent tampering with binaries

D.Disabling all seccomp and AppArmor profiles

E.Granting CAP_SYS_ADMIN to all containers by default

AnswersA, C

A securityContext with runAsNonRoot and a non-zero runAsUser forces the container process to run unprivileged, blocking root-owned process escapes and privilege escalation on the node. This directly satisfies the stem's requirement for improved container runtime security on Kubernetes nodes.

Why this answer

Option A is correct because setting runAsNonRoot: true (and typically runAsUser to a non-zero UID) in the pod/container securityContext prevents processes from running as UID 0, so a container breakout or exploited app cannot gain root privileges on the node. Option C is correct because mounting the container's root filesystem with readOnly: true blocks writes to system binaries and libraries, thwarting tampering or persistence attempts inside the container. Option B is wrong because mounting /var/run/docker.sock gives the container full control over the Docker daemon, effectively granting node-level root access.

Option D is wrong because disabling seccomp and AppArmor removes syscall and mandatory-access-control restrictions that harden the runtime. Option E is wrong because CAP_SYS_ADMIN is a highly privileged capability that enables mount, namespace, and other administrative operations, vastly expanding the attack surface.

Exam trap

The trap here is that candidates see 'securityContext' and pick every option that mentions it, forgetting that privileged: true, added capabilities, and socket mounts are anti-patterns — the exam tests whether you recognize hardening versus weakening controls.

Full explanation →

291

MCQmedium

A DevOps team uses mutable image tags like `:latest` in their deployment manifests. Under supply chain threat modeling, what vulnerability does this practice introduce?

A.Automatic revocation of TLS certificates issued by cert-manager

B.Exposition of etcd database credentials on public DNS servers

C.Escalation of RBAC permissions from Role to ClusterRole

D.Image Tag Hijacking / Malicious substitution without manifest updates

AnswerD

Mutable tags are pointers, not immutable digests. An attacker who can push to the registry retags `:latest` to a malicious image, and the next pull silently deploys it because the manifest still references the same tag, with no change to trigger review.

Why this answer

Using mutable tags like :latest introduces the risk of image tag hijacking, where an attacker replaces the image referenced by that tag with a malicious one. Because the deployment manifest still references the same tag, Kubernetes will pull the new malicious image on the next pod restart or reschedule without any manifest change, leading to supply chain compromise. This is a classic supply chain threat in containerized environments.

Exam trap

KCSA often tests supply chain threats, and candidates may confuse image tag mutability with unrelated security controls like RBAC or TLS, or underestimate that a mutable tag can be silently replaced without manifest changes.

How to eliminate wrong answers

Option A is wrong because mutable image tags have no relationship to cert-manager TLS certificate revocation; cert-manager manages certificates independently of image tags. Option B is wrong because etcd credentials are not exposed via public DNS due to image tags; this is a nonsensical combination of unrelated concepts. Option C is wrong because RBAC permissions are defined in Role and ClusterRole bindings, not influenced by image tags; image tags cannot escalate RBAC permissions.

Full explanation →

292

MCQhard

A cluster administrator wants to implement admission control auditing to record all mutating and validating requests made to the API server. Which component configuration handles this requirement?

A.Configure the kubelet audit webhook via /etc/kubernetes/audit.json.

B.Enable kube-proxy audit mode using --audit-proxy=true.

C.Set etcd logging level to DEBUG in the etcd configuration yaml.

D.Configure an audit policy file and pass its path to the API server via --audit-policy-file.

AnswerD

The API server records mutating and validating requests only when given an audit policy defining rules and levels, supplied through the --audit-policy-file flag. This satisfies the requirement to audit all such requests, since no policy means no audit events are generated.

Why this answer

The Kubernetes API server is the only component that processes admission control requests (mutating and validating webhooks, plus built-in admission plugins). To record these requests for auditing, you must configure the API server with an audit policy file using the --audit-policy-file flag, which defines what events to record and at what level (e.g., Metadata, Request, RequestResponse). This flag, along with --audit-log-path or --audit-webhook-config-file, enables audit logging of all API requests, including those that go through admission controllers.

Exam trap

KCSA often tests the misconception that audit logging can be configured on kubelet or etcd, but only the API server handles admission control and audit policy.

How to eliminate wrong answers

Option A is wrong because the kubelet does not handle admission control or API server audit logging; its audit configuration is unrelated and would not capture API server admission requests. Option B is wrong because kube-proxy is a network proxy for service routing and has no audit mode or --audit-proxy flag; it cannot record API server requests. Option C is wrong because etcd logging only records etcd's internal operations, not the admission control requests made to the API server, and DEBUG level would not provide the required audit trail.

Full explanation →

Kubernetes and Cloud Native Security Associate (KCSA, CNCF) (KCSA) (KCSA) — Questions 226–292