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

Multi-Selecteasy

Which TWO practices are essential for securing container images against supply chain vulnerabilities? (Choose two)

Select 2 answers

A.Running all container processes as the root user by default

B.Disabling container registry authentication

C.Storing plain-text passwords inside image environment variables

D.Using minimal base images (e.g., Distroless or Alpine) to reduce attack surface

E.Scanning container images for known CVEs during the CI/CD pipeline

AnswersD, E

Minimal base images such as Distroless or Alpine strip package managers, shells and unused libraries, directly shrinking the exploitable attack surface that supply chain vulnerabilities could target. Fewer installed components mean fewer known CVEs shipped inside the image, satisfying the stem's requirement to secure container images against supply chain vulnerabilities.

Why this answer

Option D is correct because using minimal base images such as Distroless or Alpine reduces the number of installed packages, libraries, and utilities, which directly shrinks the attack surface and lowers the chance that a vulnerable component is present in the image. Option E is correct because scanning container images for known CVEs during the CI/CD pipeline catches vulnerable dependencies and OS packages before deployment, enabling remediation or blocking of the build. Option A is wrong because running container processes as root by default violates least privilege and increases the impact of a container compromise.

Option B is wrong because disabling container registry authentication exposes images to unauthorized pulls and tampering. Option C is wrong because storing plain-text passwords in image environment variables leaks secrets to anyone who can inspect the image or container metadata.

Exam trap

KCSA often tests whether candidates confuse 'minimal base image' (reduces attack surface) with 'running as non-root' (reduces privilege) — both are important but answer different questions, and the exam expects you to pick the supply-chain-specific controls.

Full explanation →

MCQeasy

A compliance officer wants to continuously audit Kubernetes resource manifests for misconfigurations against security best practices before they are applied. Which tool type is best suited for this shift-left compliance approach?

A.Log shippers

B.Packet analyzers

C.Static code analysis and admission controllers

D.Kernel debuggers

AnswerC

Static analysis scans manifests in CI before they reach the cluster, catching misconfigurations at build time, while admission controllers enforce policy at apply time. Together they satisfy the stem's shift-left requirement to audit continuously before resources are applied.

Why this answer

Static code analysis tools (e.g., kube-score, Checkov, kube-linter) scan YAML manifests in CI/CD pipelines to catch misconfigurations like missing resource limits or privileged containers before deployment. Admission controllers (e.g., OPA Gatekeeper, Kyverno) enforce policies at the API server level, rejecting non-compliant resources at admission time. Together, they provide continuous, shift-left auditing that prevents misconfigured workloads from ever reaching the cluster.

Exam trap

KCSA often tests the misconception that runtime monitoring tools (log shippers, packet analyzers) provide compliance auditing, but shift-left specifically requires pre-deployment static analysis and admission control.

How to eliminate wrong answers

Option A is wrong because log shippers (e.g., Fluentd, Filebeat) collect and forward runtime logs; they do not analyze manifest content or enforce policies. Option B is wrong because packet analyzers (e.g., tcpdump, Wireshark) inspect network traffic at the packet level, not Kubernetes resource definitions. Option D is wrong because kernel debuggers (e.g., gdb, bpftrace) diagnose low-level kernel or process issues, not manifest compliance.

Full explanation →

MCQhard

An auditor is assessing compliance with NIST SP 800-53 controls for access control (AC) within a managed Kubernetes cluster. Which API object enforces fine-grained authorization decisions directly at the Kubernetes API server?

A.ValidatingWebhookConfiguration

B.NetworkPolicy

C.ClusterRoleBinding

D.ResourceQuota

AnswerC

ClusterRoleBinding grants a subject (user, group, or service account) the permissions defined in a ClusterRole across the entire cluster, and the API server's authorisation chain evaluates it for every request, satisfying NIST SP 800-53 AC controls.

Why this answer

ClusterRoleBinding is the Kubernetes RBAC API object that binds a ClusterRole (or Role) to subjects (users, groups, service accounts) cluster-wide, and the API server evaluates these bindings during authorization. It directly enforces fine-grained authorization decisions at the API server, satisfying NIST SP 800-53 AC controls for least privilege and role-based access. Without a binding, a role grants nothing — the binding is what activates the permissions.

Exam trap

KCSA often tests the confusion between admission control (ValidatingWebhookConfiguration), network policy, resource quotas, and RBAC — candidates must recognize that only RoleBinding/ClusterRoleBinding objects drive API server authorization decisions.

How to eliminate wrong answers

Option A is wrong because ValidatingWebhookConfiguration registers an admission webhook that validates API requests against custom logic, but it is not the native RBAC authorization mechanism — it is admission control, a different stage. Option B is wrong because NetworkPolicy controls pod-to-pod network traffic (L3/L4), not API server authorization decisions. Option D is wrong because ResourceQuota limits aggregate resource consumption (CPU, memory, object counts) per namespace, not who can perform which API actions.

Full explanation →

MCQhard

A Kubernetes administrator is hardening a cluster and wants to ensure that the kubelet only accepts certificates from clients that have been signed by the cluster's certificate authority. The administrator has already configured the kubelet with --client-ca-file pointing to the correct CA bundle. Which additional kubelet configuration parameter must be set to enforce certificate-based authentication and reject anonymous requests?

A.--tls-cert-file

B.--anonymous-auth=false

C.--authentication-token-webhook=true

D.--authorization-mode=Webhook

AnswerB

--anonymous-auth=false disables anonymous access to the kubelet API, forcing all requests to be authenticated. When combined with --client-ca-file, the kubelet will require clients to present a valid client certificate signed by the specified CA. This ensures that only authenticated clients can interact with the kubelet, which is a critical security hardening step. Without this, anonymous requests might still be allowed even if client certificates are configured.

Why this answer

To enforce certificate-based authentication and reject anonymous requests, the kubelet must have --anonymous-auth set to false. This setting ensures that any request without valid credentials is denied. When --client-ca-file is also configured, the kubelet will validate client certificates against the specified CA.

Together, these settings ensure that only clients with certificates signed by the cluster CA can access the kubelet API, significantly reducing the attack surface.

Exam trap

The trap here is assuming that configuring --client-ca-file alone is sufficient to require client certificates, when anonymous authentication must also be explicitly disabled.

Full explanation →

Multi-Selecthard

Which TWO mechanisms help secure Kubernetes Secrets against unauthorized access or exposure?

Select 2 answers

A.Granting cluster-admin to all application service accounts

B.Enabling encryption at rest using KMS or AES-CBC providers

C.Storing secrets in plaintext ConfigMaps for easier auditing

D.Disabling the Kubernetes audit log

E.Applying strict RBAC least-privilege roles to limit secret reading

AnswersB, E

Encryption at rest with KMS or AES-CBC providers protects etcd-stored Secret data, so anyone reading the underlying storage or a backup cannot recover plaintext credentials. This satisfies the constraint of preventing exposure when the storage layer itself is compromised.

Why this answer

Option B is correct because enabling encryption at rest with a KMS provider or the AES-CBC encryption provider ensures that Secret objects stored in etcd are encrypted on disk, so an attacker who gains access to the etcd data or its backups cannot read secret values in plaintext. Option E is correct because Kubernetes Secrets are protected primarily by RBAC authorization; applying least-privilege Roles and RoleBindings that restrict get, list, and watch on secrets to only the workloads and users that truly need them prevents unauthorized principals from reading Secret data through the API server. Option A is wrong because granting cluster-admin to all application service accounts massively over-privileges workloads and would let any compromised pod read every Secret in the cluster.

Option C is wrong because ConfigMaps are not designed to hold sensitive data and are stored unencrypted and broadly readable, so moving secrets into plaintext ConfigMaps increases exposure rather than securing them. Option D is wrong because disabling the Kubernetes audit log removes the record of who accessed or modified Secrets, eliminating detection and forensic capability instead of adding protection.

Exam trap

KCSA often tests the misconception that Kubernetes Secrets are encrypted by default, leading candidates to overlook encryption-at-rest and RBAC as the two real protective mechanisms.

Full explanation →

MCQeasy

What is the security risk of configuring `privileged: true` in a container's SecurityContext?

A.It restricts the container from writing to any attached volume.

B.It disables container isolation, granting full access to host devices and kernel capabilities

C.It forces the API server to reject all incoming TLS client requests.

D.It prevents the application from reading its own environment variables.

AnswerB

Privileged mode removes the container's namespace and cgroup isolation, giving the process unrestricted access to host devices and all kernel capabilities. This directly satisfies the stem's risk: a compromised container effectively gains root-equivalent control of the host node, defeating the containment that ordinary SecurityContext restrictions provide.

Why this answer

Setting `privileged: true` in a container's SecurityContext gives the container all Linux capabilities available to the host and disables the default isolation mechanisms (namespaces, cgroups restrictions, seccomp/AppArmor defaults). The container can then access host devices like /dev, mount filesystems, load kernel modules, and effectively act as root on the node. This is why privileged containers are considered a critical security risk in Kubernetes.

Exam trap

KCSA often tests the misconception that privileged mode is a minor permission tweak rather than a full removal of container isolation — candidates who confuse it with capabilities or readOnlyRootFilesystem pick the wrong option.

How to eliminate wrong answers

Option A is wrong because privileged mode actually grants broader write access to volumes and devices, not restricts it — volume write restrictions come from readOnly flags or filesystem permissions, not privileged mode. Option C is wrong because TLS client request handling is a function of the API server's authentication and admission configuration, not of a pod's SecurityContext. Option D is wrong because environment variables are injected by the kubelet into the container's process environment regardless of privileged status; privileged mode does not block env var reads.

Full explanation →

MCQhard

A security auditor reviews a Kubernetes cluster threat model and identifies that the Kubelet API on port 10250 permits unauthenticated requests if not configured properly. What authentication and authorization mode should be enforced on the Kubelet to prevent unauthorized remote code execution?

A.Enforcing Basic HTTP Authentication headers in kubelet configuration files

B.Disabling the Kubelet API entirely by turning off port 10250

C.Enabling anonymous requests with strict NetworkPolicy egress rules

D.Kubelet Authentication Mode set to Webhook and Authorization Mode set to Webhook

AnswerD

Configuring both authentication and authorization to Webhook makes the Kubelet validate client certificates or tokens against the API server and then check RBAC, closing the anonymous, unauthenticated access that enables remote code execution on port 10250.

Why this answer

The Kubelet exposes an HTTPS endpoint on port 10250 that, if left with anonymous authentication enabled and authorization mode AlwaysAllow, allows any unauthenticated client to execute commands in pods (e.g., via /exec, /run, /logs). Setting authentication to Webhook makes the kubelet validate client certificates or bearer tokens against the API server via SubjectAccessReview, and setting authorization to Webhook makes the kubelet delegate authorization decisions to the API server using the same mechanism. Together these enforce that only authenticated, RBAC-authorized identities (nodes, system components, or admins) can call the kubelet API.

Exam trap

KCSA often tests the misconception that NetworkPolicy or disabling the port can secure the kubelet, when the actual control is the kubelet's own authentication and authorization mode settings.

How to eliminate wrong answers

Option A is wrong because Basic HTTP Authentication is deprecated and removed from kubelet; it was never a robust mechanism and does not integrate with cluster RBAC. Option B is wrong because port 10250 is required for the control plane to manage pods, retrieve logs, and execute probes; disabling it breaks the cluster. Option C is wrong because enabling anonymous requests is precisely the misconfiguration being remediated, and NetworkPolicy cannot protect the kubelet's host-network endpoint from in-cluster attackers.

Full explanation →

MCQhard

An enterprise undergoes an ISO/IEC 27001 audit for their Kubernetes environment. The auditor requests evidence that secrets at rest are encrypted. Which configuration component enables encryption of Secret resources in etcd?

A.EncryptionConfiguration API

B.Kubelet TLS bootstrapping

C.SecretProviderClass CRD

D.ServiceAccount token volume projection

AnswerA

The EncryptionConfiguration API defines which resources are encrypted in etcd and which provider handles the encryption, such as AES-CBC or KMS v2. Supplying this file to the kube-apiserver via the --encryption-provider-config flag satisfies the auditor's requirement for evidence that Secret resources are encrypted at rest.

Why this answer

The EncryptionConfiguration API in Kubernetes defines how etcd encrypts Secret and other resources at rest, specifying providers (e.g., aesgcm, aescbc, kms) and key material. Auditors verifying ISO/IEC 27001 encryption-at-rest controls for Kubernetes look for this configuration as evidence. It is the authoritative component for encrypting Secret resources in etcd.

Exam trap

The trap is confusing in-transit controls (kubelet TLS, token projection) or external secret stores (SecretProviderClass) with etcd encryption at rest — only EncryptionConfiguration governs Secret encryption in etcd.

How to eliminate wrong answers

Option B is wrong because Kubelet TLS bootstrapping secures node-to-API-server communication in transit, not data at rest in etcd. Option C is wrong because SecretProviderClass is a Secrets Store CSI Driver CRD for mounting external secrets (e.g., from Vault) into pods, not for encrypting etcd data. Option D is wrong because ServiceAccount token volume projection manages token issuance and rotation for pods, unrelated to etcd encryption at rest.

Full explanation →

Multi-Selecteasy

Which TWO tasks are typically performed during container image vulnerability scanning? (Choose two)

Select 2 answers

A.Configuring ingress TLS certificates

B.Monitoring active Kubernetes node CPU utilization

C.Checking for insecure configuration settings or exposed secrets within image layers

D.Updating cluster network policies

E.Analyzing OS packages and application dependencies against known CVE databases

AnswersC, E

Scanning inspects image layers for misconfigurations and embedded secrets, such as hardcoded credentials or overly permissive file settings, satisfying the stem's requirement for tasks performed during container image vulnerability scanning. This static analysis of layer contents complements package vulnerability detection, addressing the configuration and secret exposure risks that image scanning tools routinely report.

Why this answer

Option C is correct because image vulnerability scanning inspects the contents of each image layer for misconfigurations such as running as root, hardcoded credentials, API keys, or other exposed secrets embedded in the filesystem. Option E is correct because scanners extract the installed OS packages (e.g., from dpkg/rpm/APK databases) and application dependencies (e.g., from package-lock.json, requirements.txt, go.mod) and compare their versions against CVE feeds like the NVD, vendor advisories, or distro security trackers. Option A is incorrect because ingress TLS certificates are configured at the Kubernetes Ingress/runtime layer, not discovered by scanning image layers.

Option B is incorrect because node CPU utilization is a runtime monitoring concern handled by tools like Prometheus or metrics-server, not image scanning. Option D is incorrect because cluster network policies are runtime Kubernetes configuration objects, not artifacts contained within a container image.

Exam trap

KCSA often tests whether candidates confuse build-time image scanning (static analysis of layers, packages, and secrets) with runtime cluster monitoring (node metrics, network policies, TLS), so picking runtime controls is the classic wrong-answer trap.

Full explanation →

Multi-Selecthard

Which THREE of the following practices are recommended when securing container images to prevent supply chain attacks in a Kubernetes environment? (Choose THREE)

Select 3 answers

A.Always run container processes as the root user (UID 0) to ensure maximum compatibility with host mounts.

B.Integrate automated vulnerability scanning into the CI/CD pipeline before pushing images to the container registry.

C.Disable container image pull policies entirely so nodes only rely on locally cached images.

D.Utilize minimal base images (such as distroless or Alpine) to reduce the potential attack surface and remove unnecessary package managers.

E.Reference images by their immutable cryptographic digest (SHA256) rather than mutable tags like latest.

AnswersB, D, E

Scanning within CI/CD catches vulnerabilities before the image reaches the registry, blocking compromised artefacts at build time. This shifts detection left, so supply chain flaws are remediated before any cluster can pull the image, satisfying the requirement to prevent rather than merely detect attacks post-deployment.

Why this answer

Option B is correct because integrating automated vulnerability scanning (e.g., Trivy, Clair, or Grype) into the CI/CD pipeline catches known CVEs in OS packages and application dependencies before an image is pushed to the registry, blocking compromised artifacts at the earliest supply-chain stage. Option D is correct because minimal base images such as distroless or Alpine contain far fewer packages, libraries, and tools (often no shell or package manager), which shrinks the attack surface and denies attackers post-exploitation utilities. Option E is correct because referencing images by their immutable SHA256 digest guarantees the exact bits that were scanned and approved are what get deployed, preventing tag-mutation or tag-poisoning attacks where a mutable tag like latest is repointed to a malicious image.

Option A is not recommended: running as root (UID 0) violates least privilege, enables container-escape and host-mount abuse, and should be replaced with a non-root user plus runAsNonRoot and dropped capabilities. Option C is not recommended: disabling image pull policies undermines the registry as the trusted source of truth, prevents digest verification and signature checks, and lets stale or tampered local caches run unchecked.

Exam trap

KCSA often tests whether candidates conflate 'convenience' practices (root user, cached images) with security best practices — the trap is picking options that sound operationally simpler but directly undermine least privilege and patch velocity.

Full explanation →

Multi-Selecteasy

Which TWO tools or built-in Kubernetes features are used to secure container privileges and behaviors?

Select 2 answers

A.Pod Security Standards

B.PersistentVolumeClaim

C.SecurityContext

D.HorizontalPodAutoscaler

E.IngressController

AnswersA, C

Pod Security Standards define the Privileged, Baseline and Restricted profiles enforced via Pod Security Admission, restricting privilege escalation, host namespaces and capabilities at the namespace level, satisfying the requirement to secure container privileges and behaviours.

Why this answer

Pod Security Standards (A) are correct because they are built-in Kubernetes policies (Privileged, Baseline, Restricted) enforced via the Pod Security Admission controller to restrict container privileges such as hostPath, hostNetwork, and privileged mode at the namespace level. SecurityContext (C) is correct because it lets you define pod- and container-level security settings like runAsUser, runAsNonRoot, readOnlyRootFilesystem, allowPrivilegeEscalation, and Linux capabilities directly in the Pod spec to control container privileges and behaviors. PersistentVolumeClaim (B) is incorrect because it only requests storage resources and has no role in privilege or behavior security.

HorizontalPodAutoscaler (D) is incorrect because it scales workloads based on metrics like CPU utilization, not security. IngressController (E) is incorrect because it manages external HTTP/HTTPS routing into the cluster, not container privilege enforcement.

Exam trap

KCSA often tests confusion between admission-time controls (Pod Security Standards/PSA) and runtime container configuration (SecurityContext), tempting candidates to select storage or scaling resources that sound security-adjacent.

Full explanation →

MCQmedium

An administrator wants to verify that etcd database defragmentation is performed periodically to reclaim storage space after large amounts of data churn. Which etcdctl command defragments an etcd member?

A.kubectl etcd-clean

B.etcdctl defrag

C.etcdctl compact

D.etcdctl cleanup storage

AnswerB

`etcdctl defrag` compacts the backend database file on a single etcd member, releasing free space left by deleted keys after heavy churn. It satisfies the stem's requirement to reclaim storage periodically. Run it against each member individually, since defragmentation is per-member and does not propagate across the cluster.

Why this answer

The etcdctl defrag command defragments an etcd member's database, reclaiming storage space after data churn (e.g., many writes and deletes). Defragmentation compacts the underlying BoltDB file, reducing its size and improving performance. It is typically run periodically on each etcd member, often after compaction.

Exam trap

KCSA often tests the confusion between compaction and defragmentation: candidates may pick 'compact' thinking it reclaims space, but only 'defrag' actually reduces the database file size.

How to eliminate wrong answers

Option A is wrong because 'kubectl etcd-clean' is not a valid command; kubectl does not manage etcd directly. Option C is wrong because 'etcdctl compact' discards old revisions but does not reclaim disk space; compaction only marks space as available for reuse, while defrag actually rewrites the database to free space. Option D is wrong because 'etcdctl cleanup storage' is not a valid etcdctl subcommand; the correct command is 'defrag'.

Full explanation →

MCQeasy

An organization is adopting Kubernetes and wants to understand where their responsibility lies under the shared responsibility model. According to the 4Cs of Cloud Native Security, who is primarily responsible for configuring the RBAC rules and network policies within the Kubernetes control plane and worker nodes?

A.The cloud service provider

B.The application development team

C.The container runtime vendor

D.The user (cluster administrator)

AnswerD

Under the 4Cs, the Cloud provider secures the Cloud layer, but the Cluster layer — including control plane configuration, RBAC rules and network policies — remains the cluster administrator's responsibility, since these are user-configured Kubernetes objects rather than provider-managed infrastructure.

Why this answer

Under the 4Cs of Cloud Native Security, the customer (cluster administrator) is responsible for everything above the Cloud layer—including RBAC role bindings, network policies, admission control, and workload configuration inside the control plane and on worker nodes. The cloud provider secures the physical and virtualized infrastructure, but Kubernetes-level authorization and segmentation are always the user's job.

Exam trap

KCSA often tests the shared responsibility boundary, so candidates who equate 'managed Kubernetes' with 'provider secures everything' incorrectly choose the cloud service provider.

How to eliminate wrong answers

Option A is wrong because the cloud service provider is responsible for the Cloud layer (physical hosts, network fabric, hypervisor, and for managed offerings the managed control plane components), not for customer-defined RBAC or NetworkPolicy objects. Option B is wrong because the application development team owns the Code and Container layers—application code, dependencies, and image contents—not cluster-wide authorization and network segmentation. Option C is wrong because the container runtime vendor supplies the runtime software (e.g., containerd, CRI-O) but does not configure a customer's RBAC rules or network policies.

Full explanation →

MCQhard

An organization wants to prevent supply chain attacks where malicious code is injected into third-party Helm charts before deployment. What mitigation technique provides cryptographic verification of Helm chart integrity and authenticity?

A.Restricting etcd database access using client certificate authentication

B.Verifying Helm chart provenance files using cryptographic signatures and public key rings

C.Disabling anonymous requests in the kube-apiserver configuration

D.Enabling Pod Security Standards in the target namespace

AnswerB

Helm provenance files contain a signed hash of the chart, verified against a public key ring. This cryptographic signature confirms the chart's origin and that its contents were not altered, satisfying the requirement to detect malicious code injected into third-party charts before deployment.

Why this answer

Helm supports provenance files (.prov) generated with helm package --sign, which use PGP/GPG signatures and a public key ring to cryptographically verify that a chart was produced by a trusted party and has not been altered. Running helm verify or installing with --verify checks the chart's integrity and authenticity against the keyring, directly mitigating tampered or injected third-party charts.

Exam trap

KCSA often tests whether candidates confuse chart provenance verification (integrity/authenticity of Helm artifacts) with cluster-side hardening controls like etcd access, anonymous request disabling, or Pod Security Standards, which address different layers of the attack surface.

How to eliminate wrong answers

Option A (Restricting etcd database access using client certificate authentication) is wrong because etcd access control protects cluster state at rest, not the integrity of Helm charts before deployment. Option C (Disabling anonymous requests in the kube-apiserver configuration) is wrong because it hardens API server authentication but does nothing to verify chart provenance or detect injected code. Option D (Enabling Pod Security Standards in the target namespace) is wrong because PSS restricts pod-level privileges at admission time and cannot detect malicious code embedded in a chart's templates or images.

Full explanation →

Multi-Selecteasy

Which TWO security features are provided by modern container runtimes like containerd or CRI-O? (Choose two)

Select 2 answers

A.Integration with Linux security modules (Seccomp, AppArmor, SELinux)

B.Management of Kubernetes RBAC roles and cluster permissions

C.Namespace isolation (PID, network, mount, user namespaces) for containers

D.Automatic deployment of service mesh sidecar proxies

E.Automatic generation of Kubernetes Ingress TLS certificates

AnswersA, C

containerd and CRI-O apply Linux security modules such as Seccomp, AppArmor and SELinux profiles to constrain container syscalls and file access, enforcing mandatory access control at the kernel level. This integration hardens containers beyond namespace isolation alone, satisfying the security-feature requirement.

Why this answer

Option A is correct because modern container runtimes such as containerd and CRI-O integrate with Linux security modules — Seccomp profiles to filter syscalls, AppArmor profiles, and SELinux labels — to constrain what container processes can do at the kernel level. Option C is correct because these runtimes rely on Linux namespaces (PID, network, mount, user, IPC, UTS) to provide process, network, filesystem, and user isolation between containers and the host. Option B is incorrect because Kubernetes RBAC roles and cluster permissions are managed by the Kubernetes API server and its authorization stack, not by the container runtime.

Option D is incorrect because service mesh sidecar injection is handled by the service mesh control plane (for example, Istio's sidecar injector admission webhook), not by containerd or CRI-O. Option E is incorrect because Ingress TLS certificate generation is performed by cert-manager or similar controllers, not by the container runtime.

Exam trap

KCSA often tests whether candidates attribute cluster-level controls (RBAC, ingress, service mesh) to the container runtime — only kernel-level isolation and LSM integration belong to the runtime.

Full explanation →

MCQeasy

An auditor is reviewing container image registries used by a Kubernetes cluster. They notice that public images are pulled directly without verification. Which security best practice should be implemented for image registries?

A.Grant cluster-admin permissions to all developers

B.Store plaintext passwords in ConfigMaps

C.Disable all network policies in the cluster

D.Use private registries with integrated vulnerability scanning and image pull policies

AnswerD

Private registries with integrated vulnerability scanning satisfy the stem's unverified public image pulls by enforcing authenticated access and admission control. Image pull policies such as Always ensure nodes retrieve vetted, scanned images rather than cached or unvetted layers, closing the supply-chain gap the auditor identified.

Why this answer

Using private registries with integrated vulnerability scanning and image pull policies ensures that only vetted, scanned images are deployed, and that the cluster enforces image provenance. This directly addresses the auditor's finding that public images are pulled without verification, because private registries can require authentication, enforce image signing (e.g., Cosign/Notary), and integrate scanners like Trivy or Clair. Kubernetes admission controllers (e.g., OPA Gatekeeper, Kyverno) can then enforce imagePullPolicy and registry allowlists.

Exam trap

KCSA often tests the misconception that Kubernetes natively verifies image signatures or that pulling from Docker Hub is inherently safe; candidates must recognize that verification requires external tooling and private registry controls.

How to eliminate wrong answers

Option A is wrong because granting cluster-admin to all developers violates least privilege and massively expands the attack surface, having nothing to do with image verification. Option B is wrong because storing plaintext passwords in ConfigMaps exposes credentials to anyone with read access to the namespace and is explicitly discouraged by Kubernetes security guidance. Option C is wrong because disabling network policies removes microsegmentation and lateral-movement controls, which is the opposite of a security best practice.

Full explanation →

MCQeasy

An administrator needs to restrict access so that a specific ServiceAccount in the production namespace can only list pods, but cannot delete or modify them. Which core Kubernetes API resource should be configured to achieve this using RBAC?

A.ValidatingWebhookConfiguration

B.ClusterRole combined with a ClusterRoleBinding

C.PodSecurityPolicy

D.Role combined with a RoleBinding

AnswerD

A Role defines the permitted verbs (list) on pods within the production namespace, and a RoleBinding grants that Role to the ServiceAccount. Namespaced RBAC therefore restricts the account to listing pods only, denying delete and modify actions.

Why this answer

A Role combined with a RoleBinding is the correct choice because RBAC in Kubernetes uses Role to define permissions within a specific namespace, and RoleBinding to grant those permissions to a subject (like a ServiceAccount) within that namespace. This allows the administrator to restrict the ServiceAccount to only list pods in the production namespace, without granting cluster-wide permissions. ClusterRole and ClusterRoleBinding would grant permissions across all namespaces, which is not desired here.

Exam trap

KCSA often tests the distinction between namespace-scoped and cluster-scoped RBAC resources, causing candidates to incorrectly choose ClusterRole and ClusterRoleBinding when the requirement is to restrict access to a single namespace.

How to eliminate wrong answers

Option A is wrong because ValidatingWebhookConfiguration is used to validate API requests via external webhooks, not to define RBAC permissions. Option B is wrong because ClusterRole combined with a ClusterRoleBinding grants permissions cluster-wide, which would allow the ServiceAccount to list pods in all namespaces, violating the requirement to restrict access to the production namespace only. Option C is wrong because PodSecurityPolicy (deprecated) was used to control pod security settings, not to manage RBAC permissions for listing pods.

Full explanation →

MCQhard

An enterprise cluster utilizes a service mesh with AuthorizationPolicies. You need to configure a policy that allows GET requests from service A to service B while explicitly denying DELETE requests on all paths. How are Istio AuthorizationPolicies evaluated when both allow and deny rules are present?

A.Only the most recently created authorization policy is evaluated

B.DENY rules take precedence and are evaluated before ALLOW rules

C.ALLOW rules take precedence and override any DENY rules

D.Rules are evaluated in alphabetical order of their object names

AnswerB

Istio evaluates DENY rules before ALLOW rules, so a matching DENY always overrides any ALLOW. The DELETE request is denied regardless of allow policies, while GET requests proceed only if an ALLOW rule also matches, giving deny precedence.

Why this answer

Istio AuthorizationPolicies follow a deny-first evaluation model: any matching DENY rule is enforced before ALLOW rules are considered. If a request matches a DENY rule, it is rejected regardless of whether an ALLOW rule would otherwise permit it. This ensures that explicit denials act as hard security boundaries that cannot be overridden by permissive allow policies.

Exam trap

The trap here is assuming ALLOW rules override DENY rules (as in some RBAC models), when Istio explicitly evaluates DENY first — a classic zero-trust gotcha.

How to eliminate wrong answers

Option A is wrong because Istio does not use creation timestamps to determine policy precedence; all policies are evaluated on every request. Option C is wrong because ALLOW rules do not override DENY rules — the opposite is true, and this misconception would create a security hole. Option D is wrong because Istio does not evaluate policies alphabetically by object name; evaluation is based on rule semantics (deny before allow), not naming conventions.

Full explanation →

Multi-Selecteasy

Which TWO layers complete the remaining set of the 4Cs of Cloud Native Security model alongside Code and Container? (Choose TWO)

Select 2 answers

A.Cache

B.Cloud

C.Compiler

D.Cluster

E.Containerd

AnswersB, D

Cloud is one of the two remaining layers of the 4Cs model, which nests Code, Container, Cluster and Cloud. It satisfies the stem's requirement to complete the set alongside Code and Container, since the model's outer layer addresses the underlying cloud provider infrastructure and its shared-responsibility controls.

Why this answer

The 4Cs of Cloud Native Security model are Code, Container, Cluster, and Cloud, so the two missing layers are Cloud (B) and Cluster (D). Cloud (B) is correct because it represents the underlying infrastructure layer — the cloud provider, its network, compute, storage, and IAM boundaries — which underpins and isolates everything above it. Cluster (D) is correct because it covers the orchestration layer (e.g., Kubernetes control plane, nodes, RBAC, network policies, and admission control) that secures how containers are scheduled and run.

The remaining options do not belong: Cache (A) is a performance/data-storage concept, not a security layer; Compiler (C) is a build toolchain component, not part of the 4Cs; and Containerd (E) is a specific container runtime that falls within the Container layer rather than being a separate layer itself.

Exam trap

The trap here is confusing implementation components (like containerd) with the conceptual 4Cs layers, or inventing plausible-sounding but non-existent layers such as Cache or Compiler.

Full explanation →

MCQeasy

Which Kubernetes control plane component is responsible for noticing and responding when nodes go down or fail health checks?

A.CoreDNS

B.etcd

C.kube-controller-manager

D.kube-proxy

AnswerC

The kube-controller-manager runs the node lifecycle controller, which monitors node heartbeats and health checks, then applies taints and evicts pods when a node becomes unreachable, satisfying the requirement to notice and respond to node failures.

Why this answer

The kube-controller-manager runs the node controller, which monitors node health via heartbeats and marks nodes NotReady or unreachable when they fail health checks, then triggers eviction of pods after the toleration period. It is the control plane component responsible for responding to node failures.

Exam trap

KCSA often tests the division of labor among control plane components, baiting candidates who attribute node health response to etcd (which stores state) or kube-proxy (which handles networking).

How to eliminate wrong answers

Option A is wrong because CoreDNS provides cluster DNS resolution for service discovery, not node health monitoring. Option B is wrong because etcd is the distributed key-value store backing the cluster state; it stores node status but does not react to node failures. Option D is wrong because kube-proxy manages iptables/IPVS rules for service networking on each node, not node lifecycle or health.

Full explanation →

MCQmedium

A security engineer identifies that an enterprise Kubernetes cluster has several cluster-admin bindings granted to user accounts that have left the company. Which Kubernetes security principle has been violated?

A.NetworkPolicy ingress traffic isolation

B.Principle of Least Privilege and proper identity/access lifecycle management

C.Pod Security Standards baseline enforcement

D.Container image vulnerability scanning policies

AnswerB

Departed users retaining cluster-admin bindings violates least privilege because excessive rights persist beyond their need, and it breaches access lifecycle management, which requires revoking permissions when identities leave. Microsoft Entra ID-integrated clusters should remove or disable those accounts, eliminating stale privileged bindings that attackers could exploit.

Why this answer

The presence of cluster-admin bindings for departed users violates the Principle of Least Privilege and proper identity/access lifecycle management. Least Privilege dictates that users should have only the permissions necessary for their role, and lifecycle management ensures access is revoked when users leave. Cluster-admin is the most powerful role and should be tightly controlled and audited.

Exam trap

KCSA often tests the ability to map a security misconfiguration (orphaned cluster-admin bindings) to the correct principle (Least Privilege and identity lifecycle), with distractors about network policies or pod security.

How to eliminate wrong answers

Option A is wrong because NetworkPolicy ingress isolation is about controlling pod-level network traffic, not user access permissions. Option C is wrong because Pod Security Standards baseline enforcement governs pod security contexts (e.g., privileged containers), not RBAC bindings. Option D is wrong because container image vulnerability scanning is about detecting vulnerabilities in images, not managing user access.

Full explanation →

MCQmedium

An administrator needs to restrict kubelets so they can only modify resources associated with their own node (such as their own Node object and Pods bound to them). Which authorization mode must be enabled alongside RBAC?

A.Node

B.ABAC

C.AlwaysDeny

D.PodSecurity

AnswerA

The Node authorizer grants kubelets permission only for API operations relating to their own node, including their Node object and Pods scheduled there. Enabling it alongside RBAC enforces the node-scoped restriction the stem requires, rather than cluster-wide access.

Why this answer

The Node authorizer is a special-purpose authorization mode designed specifically for kubelets. It restricts each kubelet's API requests to resources tied to its own node — its own Node object, Pods bound to that node, and related objects like Secrets, ConfigMaps, and PersistentVolumes referenced by those Pods. It must be enabled alongside RBAC (and typically NodeRestriction admission) so that kubelet credentials cannot read or modify cluster-wide resources.

Exam trap

KCSA often tests the confusion between authorization modes and admission controllers, tricking candidates into choosing PodSecurity (an admission plugin) when the question asks which authorization mode scopes kubelets to their own node.

How to eliminate wrong answers

Option B is wrong because ABAC is a legacy attribute-based authorization mode using static policy files; it is not node-aware and does not scope kubelets to their own node's resources. Option C is wrong because AlwaysDeny is a testing-only authorizer that denies every request, which would break the kubelet entirely rather than restrict it appropriately. Option D is wrong because PodSecurity is an admission controller (enforcing Pod Security Standards like privileged/baseline/restricted), not an authorization mode, and it does not govern which API resources a kubelet may modify.

Full explanation →

MCQeasy

An administrator notices that a compromised Pod is attempting to access the cloud provider metadata service to retrieve IAM role credentials. Which native Kubernetes resource is best suited to block this specific attack vector at the network layer?

A.ResourceQuota

B.NetworkPolicy

C.ValidatingWebhookConfiguration

D.SecurityContext

AnswerB

NetworkPolicy selects Pods by label and enforces ingress and egress rules at layer 3/4, so an egress rule can block traffic to the metadata endpoint. It satisfies the stem's requirement for a native Kubernetes resource blocking this vector at the network layer.

Why this answer

A NetworkPolicy is a Kubernetes resource that controls traffic flow at the IP address and port level (Layer 3/4). By defining egress rules, you can block a compromised Pod from reaching the cloud provider's metadata service (e.g., 169.254.169.254), thus preventing credential theft. This is the native Kubernetes network-layer control for such attack vectors.

Exam trap

The trap is confusing network-layer controls with admission or resource controls; candidates might pick SecurityContext or ValidatingWebhookConfiguration, but only NetworkPolicy operates at the network layer to block specific IPs.

How to eliminate wrong answers

Option A is wrong because ResourceQuota limits resource consumption (CPU, memory, object counts) within a namespace, not network traffic. Option C is wrong because ValidatingWebhookConfiguration is used for admission control of API requests, not for runtime network blocking. Option D is wrong because SecurityContext defines privilege and access control settings for Pods/containers (e.g., runAsUser), not network policies.

Full explanation →

MCQmedium

An administrator notices that a container in a Kubernetes cluster running containerd is attempting to write files to the root filesystem (/), which should be strictly immutable. Which configuration in the Pod's securityContext should be enforced to prevent this?

A.Set securityContext.allowPrivilegeEscalation to false

B.Set securityContext.readOnlyRootFilesystem to true

C.Set securityContext.privileged to false

D.Add the SYS_ADMIN capability to securityContext.capabilities.drop

AnswerB

Setting readOnlyRootFilesystem to true mounts the container's root filesystem read-only, so any write attempt to / fails with a filesystem error. This enforces immutability at the container level, satisfying the requirement without altering the underlying node or image.

Why this answer

securityContext.readOnlyRootFilesystem: true causes the container runtime to mount the container's root filesystem as read-only, so any write attempt to / (or any path not backed by a writable volume) fails with EROFS. This is the direct, purpose-built control for making the root filesystem immutable.

Exam trap

The trap here is that candidates see 'immutable filesystem' and pick allowPrivilegeEscalation or privileged: false because they sound security-related — the exam tests whether you know the exact securityContext field that controls root filesystem writability.

How to eliminate wrong answers

Option A is wrong because allowPrivilegeEscalation: false prevents a process from gaining more privileges than its parent (e.g., via setuid binaries), but it does not make the filesystem read-only. Option C is wrong because privileged: false simply means the container is not running in privileged mode — it still has a writable root filesystem by default. Option D is wrong because adding SYS_ADMIN grants additional capabilities (mount, namespace manipulation) and is a privilege escalation, not a filesystem restriction; capabilities.drop is the correct field for removing capabilities, not adding them.

Full explanation →

Multi-Selecthard

Which THREE of the following mechanisms are essential for securing the Kubernetes control plane against unauthorized access and privilege escalation?

Select 3 answers

A.Enforcing robust Role-Based Access Control (RBAC) with least privilege principles

B.Requiring mutual TLS (mTLS) for all internal API server and component communications

C.Using mutable `:latest` image tags for all control plane system components

D.Enabling encryption at rest for sensitive data stored in etcd

E.Setting `allowPrivilegeEscalation: true` across all default container security contexts

AnswersA, B, D

RBAC binds Kubernetes API requests to identities and restricts verbs and resources through Roles and ClusterRoles, satisfying the least-privilege constraint. Without it, any authenticated principal could escalate by creating privileged workloads. It is essential, though insufficient alone: authentication and admission controls must complement it.

Why this answer

Option A is correct because robust RBAC with least-privilege principles ensures that users, service accounts, and controllers only receive the exact permissions they need, preventing unauthorized access and privilege escalation within the cluster. Option B is correct because requiring mutual TLS (mTLS) for all internal API server and component communications authenticates both ends of every connection, protecting against man-in-the-middle attacks, spoofing, and unauthorized components joining the control plane. Option D is correct because enabling encryption at rest for sensitive data stored in etcd protects secrets, tokens, and configuration from being read directly from the backing datastore if it is compromised.

Option C is incorrect because mutable `:latest` image tags make deployments non-deterministic and can silently pull vulnerable or malicious images, weakening rather than strengthening control plane security. Option E is incorrect because setting `allowPrivilegeEscalation: true` explicitly permits containers to gain more privileges than their parent process, which directly enables privilege escalation and should be set to false.

Exam trap

KCSA often tests whether candidates recognize that allowPrivilegeEscalation: true and mutable :latest tags are anti-patterns — the exam mixes in security-sounding options that actually weaken the control plane.

Full explanation →

MCQhard

You are auditing a multi-tenant Kubernetes cluster and notice that users can read ServiceAccount tokens belonging to other namespaces through improper RBAC configuration. Which ClusterRole permission should be strictly avoided or audited to prevent token theft via secret inspection?

A.Verbs like 'get' on resource 'pods/status'.

B.Verbs like 'list' on resource 'namespaces'.

C.Verbs like 'create' on resource 'deployments'.

D.Verbs like 'get', 'list', or 'watch' on resource 'secrets' across all namespaces.

AnswerD

Cluster-wide get, list, or watch on secrets lets any bound subject read every namespace's ServiceAccount tokens, enabling impersonation and lateral movement. Auditing and removing these verbs prevents cross-namespace token theft, directly addressing the improper RBAC configuration described in the stem.

Why this answer

To prevent token theft via secret inspection, you must avoid or audit ClusterRole permissions that allow 'get', 'list', or 'watch' on 'secrets' across all namespaces. ServiceAccount tokens are stored as Secrets, so broad read access to secrets enables attackers to steal tokens and escalate privileges. Option D correctly identifies this critical permission set.

Exam trap

KCSA often tests the misconception that other permissions like pod status or namespace listing are risky, but the real danger is broad secret read access, which directly enables token theft and privilege escalation.

How to eliminate wrong answers

Option A is wrong because 'get' on 'pods/status' only allows reading pod status subresources, which does not expose ServiceAccount tokens. Option B is wrong because 'list' on 'namespaces' only allows listing namespaces, not reading secrets within them. Option C is wrong because 'create' on 'deployments' allows creating deployments, which could be abused but does not directly grant access to secrets; it is not the primary permission for token theft.

Full explanation →

MCQhard

An incident response team suspects that an attacker has gained unauthorized access to the cluster via an unencrypted etcd backup file containing sensitive cluster state. Which etcd utility should be used to securely snapshot and backup etcd data?

A.kubectl cluster-info dump --etcd

B.etcd-backup-controller

C.kubeadm backup etcd

D.etcdctl snapshot save

AnswerD

etcdctl snapshot save creates a consistent, restorable backup of the etcd key-value store, capturing cluster state including Secrets. This directly addresses the unencrypted backup exposure by producing a snapshot the team can secure and encrypt.

Why this answer

The etcdctl snapshot save command is used to create a secure, consistent backup of etcd data. It captures the entire etcd database, including cluster state and secrets, and can be encrypted or stored securely. This is the standard utility for backing up etcd in Kubernetes, especially for disaster recovery and security audits.

Exam trap

KCSA often tests the confusion between etcd backup and other backup methods, tricking candidates into selecting kubectl or kubeadm commands that do not actually back up etcd data.

How to eliminate wrong answers

Option A is wrong because 'kubectl cluster-info dump --etcd' is not a valid command; kubectl cluster-info dump outputs cluster information but does not back up etcd. Option B is wrong because 'etcd-backup-controller' is not a standard etcd utility; it may refer to a custom controller, but not the official tool. Option C is wrong because 'kubeadm backup etcd' is not a valid kubeadm command; kubeadm has 'kubeadm init' and 'kubeadm upgrade', but etcd backup is done via etcdctl.

Full explanation →

MCQmedium

An attacker gains execution in a container and attempts to perform a denial of service attack on other workloads sharing the same Kubernetes node by consuming all available CPU and memory resources. What Kubernetes feature prevents this cross-workload resource exhaustion?

A.ValidatingWebhookConfiguration rejecting pod creations

B.NetworkPolicy egress blocking rules

C.Container Resource Requests and Limits (CPU and memory)

D.ClusterRoleBindings restricting RBAC permissions

AnswerC

CPU and memory requests and limits constrain each container's consumption, so a compromised container cannot exhaust the node's shared resources. Requests guarantee scheduling reservations, while limits cap usage and trigger throttling or OOM termination, directly preventing the cross-workload denial of service described in the stem.

Why this answer

Container Resource Requests and Limits (CPU and memory) allow you to specify the minimum resources a container needs (requests) and the maximum it can consume (limits). By setting limits, you prevent a single container from monopolizing node resources, thus protecting other workloads from resource exhaustion and denial of service.

Exam trap

The trap is confusing admission control or network policies with runtime resource enforcement; candidates might think webhooks or RBAC can prevent resource exhaustion, but only resource limits directly constrain CPU/memory usage.

How to eliminate wrong answers

Option A is wrong because ValidatingWebhookConfiguration is for admission control, not runtime resource enforcement; it cannot prevent a running container from consuming resources. Option B is wrong because NetworkPolicy egress rules control network traffic, not CPU/memory consumption. Option D is wrong because ClusterRoleBindings manage RBAC permissions (who can do what in the API), not resource usage.

Full explanation →

MCQhard

You are performing a security review of etcd cluster membership. You need to list all active members of the etcd cluster and check their health status using the command line. Which etcdctl command is correct?

A.etcdctl check membership

B.etcdctl member list and etcdctl endpoint health

C.etcdctl cluster status

D.kubectl get etcdmembers

AnswerB

'etcdctl member list' enumerates cluster membership with IDs, peer URLs and client URLs, while 'etcdctl endpoint health' probes each endpoint's responsiveness and reports whether it is healthy. Together they satisfy the review requirement to list active members and verify their health status.

Why this answer

etcdctl provides two distinct subcommands for this task: 'etcdctl member list' enumerates all cluster members with their IDs, peer URLs, and client URLs, while 'etcdctl endpoint health' queries each endpoint to verify it can serve requests and is not lagging. Together they satisfy the requirement to list active members and check their health.

Exam trap

KCSA often tests whether candidates confuse etcdctl subcommands with kubectl commands, or invent plausible-sounding subcommands like 'check membership' that do not exist.

How to eliminate wrong answers

Option A is wrong because 'etcdctl check membership' is not a valid etcdctl subcommand — etcdctl uses 'member list', 'member add', 'member remove', and 'member update'. Option C is wrong because 'etcdctl cluster status' does not exist; cluster-wide status is obtained via 'etcdctl endpoint status' (which reports raft term, leader, and DB size). Option D is wrong because 'kubectl get etcdmembers' is not a Kubernetes resource — etcd is not exposed as a native Kubernetes API object, and kubectl cannot query etcd membership directly.

Full explanation →

MCQeasy

Which component in the Kubernetes control plane is directly responsible for interacting with etcd to persist and retrieve cluster state?

A.kube-controller-manager

B.kube-scheduler

C.kube-apiserver

D.kubelet

AnswerC

The kube-apiserver is the sole control-plane component that reads from and writes to etcd, serving as the cluster's persistent state gateway. Controllers and schedulers never touch etcd directly; they watch the API server. This satisfies the stem's requirement for the component directly responsible for persisting and retrieving cluster state.

Why this answer

The kube-apiserver is the only control plane component that talks directly to etcd. It exposes the REST API, validates and mutates objects via admission controllers, and persists/retrieves all cluster state in etcd. Other components (scheduler, controller-manager, kubelet) interact with the API server, never with etcd directly.

Exam trap

KCSA often tests the misconception that other control plane components (scheduler, controller-manager) communicate with etcd, when in fact only the kube-apiserver does.

How to eliminate wrong answers

Option A is wrong because kube-controller-manager watches the API server for resource changes and reconciles desired state; it does not connect to etcd. Option B is wrong because kube-scheduler only binds pods to nodes via the API server and has no etcd client. Option D is wrong because kubelet runs on nodes, receives pod specs from the API server, and manages containers; it never touches etcd.

Full explanation →

MCQmedium

According to the CIS Kubernetes Benchmark, anonymous requests to the Kubernetes API server should be disabled. Which kube-apiserver flag enforces this setting?

A.--authorization-mode=Node,RBAC

B.--anonymous-auth=false

C.--enable-admission-plugins

D.--insecure-port=0

AnswerB

Setting `--anonymous-auth=false` on the kube-apiserver rejects unauthenticated requests to the API server, satisfying the CIS Kubernetes Benchmark control that requires anonymous access to be disabled. Requests without valid credentials then receive a 401 Unauthorised response rather than being mapped to the `system:anonymous` user and `system:unauthenticated` group.

Why this answer

The --anonymous-auth=false flag on the kube-apiserver disables anonymous requests, as recommended by the CIS Kubernetes Benchmark. This forces all requests to be authenticated.

Exam trap

KCSA often tests the difference between authentication and authorization flags; candidates may confuse --authorization-mode with --anonymous-auth, leading to wrong answers.

How to eliminate wrong answers

Option A is wrong because --authorization-mode=Node,RBAC controls authorization, not authentication; it does not disable anonymous access. Option C is wrong because --enable-admission-plugins enables admission controllers, which are unrelated to anonymous authentication. Option D is wrong because --insecure-port=0 disables the insecure HTTP port, but anonymous requests can still be made over HTTPS if --anonymous-auth is not set to false.

Full explanation →

Multi-Selecthard

An organization is hardening their Kubernetes cluster configuration to secure the Cluster layer. Which THREE configurations or practices should they implement? (Choose THREE)

Select 3 answers

A.Disabling anonymous requests to the Kubernetes API server

B.Using strong authentication mechanisms (e.g., OIDC) for cluster access

C.Enabling and configuring Kubernetes audit logging

D.Using public distroless base images for Dockerfiles

E.Writing unit tests for JavaScript frontend applications

AnswersA, B, C

Disabling anonymous requests forces authentication before any API call, closing unauthenticated access to cluster resources. This satisfies the Cluster layer hardening requirement by removing a default exposure that lets anyone query or modify the API server.

Why this answer

Option A is correct because disabling anonymous requests to the Kubernetes API server (via the --anonymous-auth=false flag on kube-apiserver) prevents unauthenticated users from reaching API endpoints, which is a fundamental Cluster-layer hardening control. Option B is correct because strong authentication mechanisms such as OIDC ensure that cluster access is tied to verified identities rather than weak or shared credentials, directly securing the Cluster layer's control plane access. Option C is correct because enabling and configuring Kubernetes audit logging records API requests and actions, providing the visibility needed to detect and investigate suspicious activity against the cluster.

Options D and E are not Cluster-layer hardening practices: distroless base images address container image and workload security, while unit tests for JavaScript frontend applications concern application code quality and are unrelated to securing the Kubernetes cluster configuration.

Exam trap

The trap is mixing layers — candidates may select distroless images (Container layer) or unit tests (Code layer) because they sound security-related, but the question specifically asks about the Cluster layer.

Full explanation →

MCQeasy

An enterprise is adopting the Cloud Native Security Framework to map their controls. Which of the 4Cs of Cloud Native Security represents the outermost layer encompassing physical data centers and hardware?

A.Clusters

B.Cloud

C.Code

D.Containers

AnswerB

The Cloud layer is the outermost of the 4Cs, covering the physical data centres, hardware, and underlying infrastructure that hosts everything above it. Controls here address physical security and provider-level protections, forming the foundation beneath clusters, containers, and code.

Why this answer

The Cloud layer is the outermost of the 4Cs of Cloud Native Security (Cloud, Clusters, Containers, Code), representing the underlying infrastructure — physical data centers, hardware, and the cloud provider's IaaS layer. It encompasses the security of the cloud provider's environment, including physical security, hypervisor security, and network infrastructure. The 4Cs model, popularized by Kubernetes, emphasizes that security at each inner layer depends on the outer layer.

Exam trap

KCSA often tests the ordering and scope of the 4Cs, causing candidates to confuse the Cloud layer (physical infrastructure) with the Clusters layer (Kubernetes control plane) because both sound 'infrastructure-related'.

How to eliminate wrong answers

Option A is wrong because Clusters is the second layer (after Cloud) and covers the Kubernetes control plane, nodes, and cluster networking, not physical data centers. Option C is wrong because Code is the innermost layer, covering application source code, dependencies, and CI/CD pipeline security. Option D is wrong because Containers is the third layer, covering container images, runtime, and orchestration, not the physical infrastructure.

Full explanation →

Multi-Selecteasy

Which THREE methods can be used to inject Kubernetes Secrets into a running pod?

Select 3 answers

A.Injected as environment variables

B.Compiled directly into the container image binary

C.Mounted as files inside a volume

D.Injected via projected volumes

E.Injected through kernel sysctl parameters

AnswersA, C, D

Environment variables inject secret values directly into a container's process environment at pod start, satisfying the requirement that secrets reach a running pod without extra volume mounts. Kubernetes populates them from the Secret via `envFrom` or `valueFrom.secretKeyRef`, making this one of the three supported injection methods.

Why this answer

Option A is correct because Kubernetes natively supports exposing a Secret's key-value pairs as environment variables in a container via the env or envFrom fields with valueFrom.secretKeyRef or secretRef, making the data available to the process at runtime. Option C is correct because a Secret can be mounted as a volume (secret volume type), which writes each key as a file inside the container's filesystem, a common pattern for config files and credentials. Option D is correct because projected volumes allow combining multiple sources—including Secrets, ConfigMaps, downwardAPI, and serviceAccountToken—into a single mounted volume, and Secrets are explicitly one of the supported projection sources.

Option B is incorrect because baking secrets into a container image embeds them in the image layers, which is not an injection method at runtime and is considered an anti-pattern since the image is static and shared. Option E is incorrect because kernel sysctl parameters are tunable kernel settings exposed via the sysctl interface and have no mechanism for delivering Kubernetes Secret data into a pod.

Exam trap

KCSA often tests whether candidates confuse Secret delivery mechanisms with image build practices, so watch for distractors like 'compiled into the image' or 'sysctl' that sound technical but have no relationship to how the kubelet injects Secret data.

Full explanation →

MCQmedium

By default, how are Kubernetes Secrets stored in etcd when created without additional encryption-at-rest configurations?

A.Hashed using SHA-256 with a random salt

B.Encrypted using the node's TPM chip

C.Encrypted using AES-256 automatically

D.Encoded in Base64 plaintext

AnswerD

Kubernetes Secrets are stored in etcd as Base64-encoded strings, which is reversible encoding, not encryption. This satisfies the default-behaviour constraint: without configuring an EncryptionConfiguration with a KMS or aescbc provider, anyone with etcd access can decode the values.

Why this answer

By default, Kubernetes Secrets are stored in etcd as Base64-encoded strings, which is an encoding, not encryption. Anyone with read access to etcd or the ability to fetch the Secret via the API can trivially decode the value, which is why encryption at rest must be explicitly configured via EncryptionConfiguration.

Exam trap

KCSA often tests the distinction between encoding and encryption — candidates see 'Base64' and assume it implies some security, but Base64 is reversible by anyone and provides no confidentiality whatsoever.

How to eliminate wrong answers

Option A is wrong because Kubernetes does not hash Secret values — hashing is one-way and would make the Secret unusable, since the kubelet must retrieve the original plaintext to inject it. Option B is wrong because Kubernetes has no built-in TPM-based encryption for etcd data; TPMs are used for node identity and disk encryption at the OS level, not for Secret storage. Option C is wrong because AES-256 encryption at rest is not automatic — it requires an explicit EncryptionConfiguration with an aescbc, aesgcm, or KMS provider and the --encryption-provider-config flag on the apiserver.

Full explanation →

Multi-Selectmedium

Which TWO features are typically provided by service mesh architectures to enhance platform security? (Choose two)

Select 2 answers

A.Automatic kernel patch management for worker nodes

B.Fine-grained Layer 7 authorization policies between services

C.Provisioning of persistent block storage volumes

D.Automatic mutual TLS (mTLS) encryption for pod-to-pod communication

E.Managing container registry authentication tokens

AnswersB, D

Service meshes enforce Layer 7 policy at the sidecar proxy, evaluating HTTP method, path and identity per request rather than merely permitting a TCP connection. This delivers the fine-grained, identity-aware authorisation between services that network-level controls cannot express.

Why this answer

Option B is correct because service meshes such as Istio and Linkerd enforce fine-grained Layer 7 authorization policies (for example, Istio AuthorizationPolicy or Linkerd's HTTPRoute-based policies) that control which services may call specific HTTP methods, paths, or gRPC methods, providing identity-aware, request-level access control between workloads. Option D is correct because service meshes automatically provision and rotate mutual TLS (mTLS) certificates for pod-to-pod communication, typically via a sidecar proxy (Envoy) or ambient node proxy, giving each workload a SPIFFE-based cryptographic identity and encrypting all east-west traffic without application changes. Option A is not a service mesh feature; kernel patching of worker nodes is handled by node OS update tooling or managed Kubernetes node image upgrades.

Option C is not a service mesh feature; persistent block storage volumes are provisioned by CSI drivers and storage classes, not by the mesh data plane. Option E is not a service mesh feature; container registry authentication tokens are managed by Kubernetes image pull secrets, kubelet credential providers, or registry-level IAM, not by the service mesh.

Exam trap

KCSA often tests whether candidates confuse service mesh security features (mTLS, L7 authorization) with infrastructure concerns (kernel patching, storage, registry auth), so picking non-mesh options is the common mistake.

Full explanation →

Multi-Selectmedium

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

Select 3 answers

A.baseline

B.isolated

C.privileged

D.restricted

E.secure

AnswersA, C, D

baseline is one of the three official Pod Security Standard levels. It blocks known privilege escalations while permitting default pod configurations, sitting between the permissive privileged level and the hardened restricted level, and is enforced via namespace labels.

Why this answer

The three official Pod Security Standard enforcement levels defined by Kubernetes are privileged, baseline, and restricted. Option A (baseline) is correct because it is the minimally restrictive policy that prevents known privilege escalations while allowing default pod configurations. Option C (privileged) is correct because it is the unrestricted policy allowing the widest possible permissions, intended for trusted workloads such as system-level components.

Option D (restricted) is correct because it is the most restrictive policy, enforcing current hardening best practices like requiring non-root users and dropping capabilities. Options B (isolated) and E (secure) are not recognized enforcement levels; they are not part of the Kubernetes Pod Security Standards, which only define privileged, baseline, and restricted.

Exam trap

The trap here is confusing the Pod Security Standard levels with other security concepts like network isolation or generic terms like 'secure', leading candidates to select non-existent options.

Full explanation →

Multi-Selecteasy

Which TWO actions can be performed using Kubernetes RBAC rules?

Select 2 answers

A.Granting permission to create deployments cluster-wide

B.Encrypting secret values stored in etcd

C.Allocating storage capacity for PersistentVolumes

D.Enforcing Pod Security Standards on namespaces

E.Granting permission to read ConfigMaps in a namespace

AnswersA, E

Kubernetes RBAC supports ClusterRole and ClusterRoleBinding resources, which grant permissions across all namespaces rather than within one. Creating deployments cluster-wide therefore maps directly to a ClusterRole bound via ClusterRoleBinding, satisfying the stem's requirement for an action achievable through RBAC rules.

Why this answer

RBAC (Role-Based Access Control) in Kubernetes governs who can perform which verbs on which resources via Roles/ClusterRoles bound with RoleBindings/ClusterBindings, so option A is correct: a ClusterRole granting the 'create' verb on 'deployments' (apps API group) bound cluster-wide allows creating deployments in any namespace. Option E is also correct: a Role granting the 'get'/'list'/'watch' verbs on 'configmaps' in a specific namespace, bound via a RoleBinding, permits reading ConfigMaps only in that namespace. Option B is wrong because encryption of Secret data at rest in etcd is handled by the API server's EncryptionConfiguration (EncryptionConfiguration with an aescbc/aesgcm/kms provider), not RBAC.

Option C is wrong because PersistentVolume capacity is provisioned by StorageClasses, CSI drivers, or static PV definitions, not by RBAC rules. Option D is wrong because Pod Security Standards are enforced via the Pod Security Admission controller using namespace labels (pod-security.kubernetes.io/enforce), not RBAC.

Exam trap

KCSA often tests the boundary between authorization (RBAC) and other control-plane functions — candidates incorrectly attribute encryption, storage, or admission enforcement to RBAC because those are all 'security-adjacent' concepts.

Full explanation →

MCQhard

A security architect is designing a multi-tenant Kubernetes platform. They need to ensure that a compromise in one tenant's namespace cannot allow packet sniffing or unauthorized traffic interception from another tenant's pods. Which Kubernetes feature should they implement to satisfy cloud native network isolation principles?

A.Kubernetes RBAC RoleBindings

B.ResourceQuotas

C.Kubernetes NetworkPolicies

D.PodSecurityStandards

AnswerC

NetworkPolicies enforce pod-level firewall rules, restricting ingress and egress traffic between namespaces so one tenant's pods cannot reach another's. This satisfies the isolation requirement by default-deny policies per namespace. However, they control traffic flow, not packet sniffing on the shared node network, so encryption or separate nodes may still be needed.

Why this answer

Kubernetes NetworkPolicies are the native mechanism for controlling pod-to-pod traffic at L3/L4, allowing the architect to define ingress and egress rules that restrict which pods can communicate. By default, Kubernetes allows all pod-to-pod traffic within a cluster, so a compromised pod in one tenant namespace could sniff or reach pods in another. NetworkPolicies enforce isolation by selecting pods via labels and permitting only explicitly allowed flows, satisfying the cloud-native network isolation principle for multi-tenancy.

Exam trap

KCSA often tests the misconception that RBAC or PodSecurityStandards provide network isolation, when in fact only NetworkPolicies (enforced by a supporting CNI) control pod-to-pod traffic.

How to eliminate wrong answers

Option A is wrong because RBAC RoleBindings control API server authorization (who can perform Kubernetes API actions), not network traffic between pods. Option B is wrong because ResourceQuotas limit namespace resource consumption (CPU, memory, object counts) and have no bearing on packet-level isolation. Option D is wrong because PodSecurityStandards govern pod security contexts (privileged, hostPath, capabilities) and do not restrict network communication between pods.

Full explanation →

Multi-Selecteasy

When evaluating a Kubernetes cluster against security and compliance baselines, which TWO tools are commonly used for automated auditing and benchmarking? (Choose TWO)

Select 2 answers

A.Kustomize

B.kube-bench

C.Helm

D.Kubescape

E.Kubectl

AnswersB, D

kube-bench automates the CIS Kubernetes Benchmark, checking control plane and node configuration against hardening baselines. It satisfies the auditing requirement by inspecting running components and reporting pass/fail results, making it a standard benchmarking tool for cluster compliance assessments.

Why this answer

kube-bench (B) is correct because it is an open-source tool from Aqua Security that automates the checks of the CIS Kubernetes Benchmark, inspecting the cluster's control plane components, kubelet, and configuration files to report pass/fail results against the benchmark. Kubescape (D) is correct because it is an ARMO tool that performs automated security and compliance scanning of Kubernetes clusters, mapping results to frameworks such as the NSA/CISA Kubernetes Hardening Guidance, MITRE ATT&CK, and CIS benchmarks. Kustomize (A) is a configuration management tool for customizing Kubernetes YAML manifests via overlays, not an auditing or benchmarking tool.

Helm (C) is a package manager for deploying and managing Kubernetes applications using charts, not a compliance scanner. Kubectl (E) is the Kubernetes command-line client for interacting with the API server, not an automated auditing or benchmarking tool.

Exam trap

KCSA often tests the confusion between general Kubernetes tools (Helm, Kustomize, kubectl) and specialized security auditing tools, leading candidates to select non-security tools.

Full explanation →

MCQhard

You are configuring an Ingress resource using the NGINX Ingress Controller to expose a sensitive internal application. To prevent unauthorized clients from connecting, you want to enable mutual TLS authentication at the ingress layer. Which annotation is required in the Ingress resource definition to specify the Kubernetes Secret containing the trusted Client CA certificate?

A.ingress.kubernetes.io/backend-protocol

B.nginx.ingress.kubernetes.io/auth-tls-secret

C.kubernetes.io/ingress.class

D.nginx.ingress.kubernetes.io/ssl-redirect

AnswerB

The auth-tls-secret annotation names the Kubernetes Secret holding the trusted Client CA bundle, enabling the NGINX Ingress Controller to verify client certificates during the mutual TLS handshake, satisfying the stem's requirement to authenticate clients at the ingress layer.

Why this answer

The annotation nginx.ingress.kubernetes.io/auth-tls-secret is the NGINX Ingress Controller directive that specifies the Kubernetes Secret containing the CA certificate used to verify client certificates for mutual TLS. When set, the controller enforces client certificate authentication at the ingress layer, rejecting connections that do not present a certificate signed by the trusted CA. This is the correct annotation for enabling mTLS with a trusted Client CA.

Exam trap

KCSA often tests the confusion between annotations that control TLS termination (ssl-redirect, backend-protocol) and those that enforce client certificate verification (auth-tls-secret), causing candidates to pick a TLS-related but incorrect annotation.

How to eliminate wrong answers

Option A is wrong because ingress.kubernetes.io/backend-protocol controls how the ingress communicates with the backend (HTTP, HTTPS, GRPC), not client certificate verification. Option C is wrong because kubernetes.io/ingress.class selects which ingress controller handles the resource — it has nothing to do with mTLS. Option D is wrong because nginx.ingress.kubernetes.io/ssl-redirect forces HTTP-to-HTTPS redirection, which is unrelated to client certificate authentication.

Full explanation →

MCQhard

You want to ensure that a newly created Role in namespace 'finance' cannot be modified or deleted by regular developers who have edit permissions. Which RBAC feature or design prevents unauthorized privilege escalation through Role manipulation?

A.Enabling Pod Security Standards on the finance namespace.

B.Setting the Role resource to immutable via 'immutable: true'.

C.A mandatory MutatingWebhookConfiguration that strips administrative verbs.

D.The API server's built-in privilege escalation prevention check, which blocks users from granting permissions they do not hold.

AnswerD

Kubernetes' API server enforces privilege escalation prevention: a user cannot create or update a Role granting permissions they do not already hold, unless they have the escalate verb. This blocks developers with edit rights from crafting a Role that exceeds their own privileges, preventing escalation through Role manipulation.

Why this answer

Kubernetes RBAC has a built-in privilege escalation prevention check: the API server blocks a user from creating or updating a Role/ClusterRole that grants permissions the user does not already hold (unless they have the 'escalate' or 'bind' verb). This prevents a developer with edit rights from crafting a Role that grants cluster-admin and then binding to it.

Exam trap

The trap is inventing non-existent features (immutable Roles) or misapplying unrelated controls (Pod Security Standards, webhooks) instead of recognizing Kubernetes' native privilege escalation prevention.

How to eliminate wrong answers

Option A is wrong because Pod Security Standards govern pod security contexts (privileged, hostPath, etc.), not RBAC role manipulation. Option B is wrong because Kubernetes Role/ClusterRole objects do not support an 'immutable: true' field — that field exists on ConfigMaps and Secrets, not RBAC resources. Option C is wrong because a MutatingWebhookConfiguration is not a built-in RBAC control and would be a custom, fragile workaround rather than the native mechanism.

Full explanation →

MCQeasy

A security analyst wants to scan container images for known Common Vulnerabilities and Exposures (CVEs) as part of a continuous compliance pipeline. Which tool is widely used for this purpose?

A.Envoy

B.CoreDNS

C.Trivy

D.Calico

AnswerC

Trivy scans container images for known CVEs, satisfying the continuous compliance pipeline requirement. It inspects OS packages and language dependencies, matching them against vulnerability databases. Unlike runtime tools such as Falco, which detect behavioural threats, Trivy performs static image analysis, making it suited to pre-deployment pipeline scanning.

Why this answer

Trivy is an open-source vulnerability scanner for container images, filesystems, and Git repositories. It detects known CVEs in OS packages and application dependencies, making it ideal for continuous compliance pipelines.

Exam trap

KCSA often tests the confusion between networking tools (Envoy, Calico, CoreDNS) and security scanning tools, causing candidates to pick a CNI or DNS component instead of Trivy.

How to eliminate wrong answers

Option A is wrong because Envoy is a service proxy for networking, not a vulnerability scanner. Option B is wrong because CoreDNS is a DNS server for Kubernetes service discovery. Option D is wrong because Calico is a CNI plugin for network policy and security, not an image scanner.

Full explanation →

MCQeasy

Which attack vector involves tricking a Kubernetes cluster user or service into executing unintended actions via authenticated sessions, frequently mitigated by robust CSRF defenses and proper API design?

A.Cross-Site Request Forgery (CSRF)

B.Denial of Service via memory leaks

C.Container escape via kernel flaw

D.Image tag mutation

AnswerA

CSRF exploits a victim's authenticated session by luring them into submitting forged requests, causing unintended cluster actions. Robust CSRF tokens and sound API design mitigate it, matching the stem's description of tricking users or services through authenticated sessions.

Why this answer

Cross-Site Request Forgery (CSRF) tricks an authenticated user's browser or session into sending unintended requests to a trusted application — for example, a malicious page causing a logged-in Kubernetes dashboard user to issue API calls. Mitigations include CSRF tokens, SameSite cookies, and requiring re-authentication for sensitive operations, which is exactly what the question describes.

Exam trap

KCSA often tests whether candidates can distinguish session-abuse attacks (CSRF) from supply-chain (image tag mutation), isolation-break (container escape), and availability (DoS) attacks, luring them toward the more 'Kubernetes-sounding' options.

How to eliminate wrong answers

Option B is wrong because DoS via memory leaks exhausts resources to cause unavailability — it does not involve tricking an authenticated session into performing unintended actions. Option C is wrong because container escape via kernel flaw exploits a vulnerability in the kernel or runtime to break isolation, not to abuse a user's authenticated session. Option D is wrong because image tag mutation involves overwriting a mutable tag (e.g., :latest) in a registry to deliver malicious code — a supply-chain attack, not a session-abuse attack.

Full explanation →

MCQhard

In a zero-trust Kubernetes architecture, an attacker attempts to exploit the Kubernetes API server via a Server-Side Request Forgery (SSRF) flaw in a poorly written custom controller. Which defense-in-depth mechanism specifically protects against unauthorized API requests originating from inside the cluster network?

A.Configuring Horizontal Pod Autoscalers to limit request rates

B.Enabling Pod Security Standards in baseline mode across all namespaces

C.Mandatory client certificate authentication and rigorous RBAC authorization on API endpoints

D.Disabling the Kubelet read-only port on all worker nodes

AnswerC

Client certificate authentication forces every caller to prove identity cryptographically, and RBAC then authorises each verb on each resource. An SSRF flaw in a controller cannot forge a valid certificate, so requests from inside the cluster network are rejected before reaching API logic.

Why this answer

Client certificate authentication combined with strict RBAC ensures that every request to the API server is cryptographically tied to an authenticated identity and authorized against explicit policy, so an SSRF from a compromised controller cannot impersonate another principal or escalate privileges. Even if the attacker crafts requests from inside the cluster network, the API server rejects them without valid credentials and matching RBAC bindings. This is the core zero-trust 'never trust, always verify' control at the API boundary.

Exam trap

KCSA often tests the confusion between pod-level hardening controls (Pod Security Standards, disabling kubelet ports) and identity-based API server controls (mTLS + RBAC), tricking candidates into picking a pod-hardening option when the question is really about authenticating API requests.

How to eliminate wrong answers

Option A is wrong because Horizontal Pod Autoscalers only adjust replica counts based on CPU/memory metrics — they provide no authentication or authorization and do nothing to stop unauthorized API calls. Option B is wrong because Pod Security Standards baseline mode restricts pod-level privileges (host namespaces, privileged containers) but does not authenticate or authorize API server requests, so an SSRF payload still reaches the API server. Option D is wrong because disabling the Kubelet read-only port (10255) closes an information-disclosure vector on nodes but has no bearing on API server authentication or SSRF-originated requests.

Full explanation →

Multi-Selectmedium

Which THREE of the following criteria should be evaluated when reviewing Kubernetes RBAC policies to ensure least privilege? (Choose THREE)

Select 3 answers

A.Carefully audit permissions that allow impersonation or binding of roles.

B.Limit the use of cluster-scoped ClusterRoleBindings to cases where namespace-scoped Roles are insufficient.

C.Ensure anonymous users have write access to all namespaces.

D.Avoid granting wildcard permissions (*) on sensitive resources like secrets or cluster roles.

E.Grant cluster-admin permissions to every service account by default.

AnswersA, B, D

Impersonation and role-binding permissions let a subject assume another identity or grant itself extra rights, bypassing namespace boundaries. Auditing these satisfies the least-privilege criterion by exposing privilege-escalation paths that ordinary permission reviews miss, since the granted verb is not the resource access itself.

Why this answer

Option A is correct because permissions such as impersonate and bind/escalate on users, groups, serviceaccounts, or roles let a subject assume other identities or grant themselves broader rights, directly undermining least privilege and requiring careful audit. Option B is correct because ClusterRoleBindings grant permissions across all namespaces and cluster-scoped resources, so they should be reserved for cases where a namespaced RoleBinding cannot provide the needed access. Option D is correct because wildcard (*) verbs or resources on sensitive objects like secrets, roles, and clusterroles can silently grant far more access than intended, violating least privilege.

Option C is incorrect because anonymous write access to all namespaces is a severe over-permission and the opposite of least privilege. Option E is incorrect because granting cluster-admin to every service account by default is excessive privilege and a well-known anti-pattern.

Exam trap

KCSA often tests least-privilege RBAC by mixing in obviously bad options (anonymous write, cluster-admin for all) with subtle good ones (auditing impersonation/bind, limiting ClusterRoleBindings, avoiding wildcards), so candidates must recognize the anti-patterns quickly.

Full explanation →

MCQmedium

You need to ensure that an ingress controller processing TLS termination uses strong cryptographic ciphers and disables outdated protocols such as TLSv1.0 and TLSv1.1. Where are these TLS configuration settings typically managed in an NGINX Ingress deployment?

A.Ingress controller ConfigMap parameters such as ssl-ciphers and ssl-protocols

B.The core DNS configuration map

C.The kube-apiserver static pod manifest file

D.Persistent Volume Claim storage classes

AnswerA

NGINX Ingress reads TLS policy from controller-level ConfigMap keys, specifically `ssl-ciphers` and `ssl-protocols`, which set the cipher suite list and minimum protocol version for every server block. This satisfies the requirement to disable TLSv1.0 and TLSv1.1 and enforce strong ciphers centrally, rather than per-Ingress resource annotations.

Why this answer

In an NGINX Ingress deployment, TLS settings for the ingress controller are configured globally via ConfigMap parameters such as ssl-ciphers and ssl-protocols. These parameters allow administrators to specify the cipher suite and the minimum TLS version (e.g., TLSv1.2) that the controller will accept, ensuring strong cryptography and disabling outdated protocols like TLSv1.0 and TLSv1.1. This ConfigMap is typically named nginx-configuration and resides in the ingress-nginx namespace, and changes are applied by reloading the controller.

Exam trap

KCSA often tests the misconception that TLS settings for ingress are configured in the Ingress resource itself or in the API server, when in fact they are managed globally via the ingress controller's ConfigMap.

How to eliminate wrong answers

Option B is wrong because the core DNS configuration map (CoreDNS ConfigMap) is used to configure cluster DNS resolution, not ingress TLS settings. Option C is wrong because the kube-apiserver static pod manifest defines the API server's runtime parameters, not the ingress controller's TLS configuration. Option D is wrong because Persistent Volume Claim storage classes define storage provisioning policies, not cryptographic settings for ingress.

Full explanation →

MCQhard

An enterprise Kubernetes cluster uses a service mesh with strict authorization policies configured. A developer complains that their frontend service cannot communicate with the backend database service. Upon inspecting the mesh configuration, you notice a PeerAuthentication resource set to STRICT mode. What does this setting enforce?

A.Pod security standards must be enforced at the baseline level

B.Network policies must block all traffic from outside the namespace

C.All external ingress traffic must pass through a Web Application Firewall

D.All incoming traffic to the targeted workloads must use mutual TLS encryption

AnswerD

PeerAuthentication STRICT mode enforces mutual TLS on all inbound connections to the targeted workloads, so the frontend must present a valid mesh certificate before the backend accepts traffic. Plaintext connections are rejected, satisfying the strict encryption requirement that blocks the developer's unauthenticated request.

Why this answer

A PeerAuthentication resource in STRICT mode enforces mutual TLS (mTLS) for all incoming traffic to the targeted workloads, meaning both client and server must present valid certificates. This ensures encryption and identity verification between services in the mesh, and plaintext traffic is rejected. It is a core Istio security primitive for zero-trust service-to-service communication.

Exam trap

KCSA often tests candidates who confuse PeerAuthentication (mTLS enforcement) with AuthorizationPolicy (access control) or NetworkPolicy (L3/L4 filtering), leading them to pick network or WAF-related answers.

How to eliminate wrong answers

Option A is wrong because Pod Security Standards are enforced by Pod Security Admission, not by PeerAuthentication, which deals with transport security. Option B is wrong because network policies are Kubernetes NetworkPolicy or Cilium resources controlling L3/L4 traffic, not mTLS enforcement. Option C is wrong because WAF integration for external ingress is handled by ingress gateways or external WAF services, not by PeerAuthentication, which governs mesh-internal mTLS.

Full explanation →

Multi-Selecthard

Which TWO of the following kubelet security configurations are critical for preventing container escape and unauthorized node API access? (Choose TWO)

Select 2 answers

A.Enable anonymous authentication on the kubelet secure port.

B.Run kubelet containers in privileged mode.

C.Configure kubelet authorization mode to Webhook.

D.Set authorization.mode to AlwaysAllow.

E.Disable the unauthenticated read-only port by setting readOnlyPort to 0.

AnswersC, E

Webhook authorisation delegates kubelet API access decisions to the API server, so it evaluates RBAC and enforces authentication. This satisfies the constraint against unauthorised node API access, replacing permissive AlwaysAllow with centrally governed, identity-based checks.

Why this answer

Option C is correct because setting the kubelet authorization mode to Webhook delegates authorization decisions to the API server's SubjectAccessReview, ensuring that only authenticated and properly authorized subjects (such as nodes and system components) can perform actions against the kubelet's API, which prevents unauthorized node API access. Option E is correct because the kubelet's read-only port (default 10255) serves unauthenticated and unencrypted data; setting readOnlyPort to 0 disables it entirely, closing an anonymous access vector that could leak node and pod information or be abused. Option A is wrong because enabling anonymous authentication on the secure port would allow unauthenticated requests, directly undermining access control rather than preventing it.

Option B is wrong because running kubelet containers in privileged mode grants broad host capabilities and increases container-escape risk instead of mitigating it. Option D is wrong because authorization.mode AlwaysAllow permits all requests without any authorization checks, which is the opposite of a secure configuration.

Exam trap

KCSA often tests the pairing of authentication and authorization hardening — candidates pick 'enable anonymous auth' or 'AlwaysAllow' thinking they simplify access, when both are exactly the misconfigurations the question is warning against.

Full explanation →

Multi-Selectmedium

Which TWO of the following practices directly address security concerns within the 'Container' layer of the 4Cs of Cloud Native Security?

Select 2 answers

A.Scanning container images for known Common Vulnerabilities and Exposures (CVEs) prior to deployment.

B.Running containers with a non-root user ID in the Dockerfile.

C.Encrypting data at rest using cloud storage encryption keys.

D.Configuring cloud provider IAM policies for virtual machine instances.

E.Setting up Kubernetes NetworkPolicies between namespaces.

AnswersA, B

Image scanning inspects layers and installed packages for known CVEs before deployment, so vulnerable components are caught while the artefact is still in the registry. This directly addresses the Container layer, since the image itself is the container-layer artefact under scrutiny.

Why this answer

Option A is correct because scanning container images for known CVEs directly hardens the container layer by detecting vulnerable packages and base-image components before the image is deployed. Option B is correct because specifying a non-root user ID in the Dockerfile (via the USER instruction) enforces least privilege inside the container, reducing the impact of a container breakout or compromised process. Option C is not part of the container layer; encrypting data at rest with cloud storage keys belongs to the cloud/infrastructure or data layer.

Option D is also outside the container layer, as IAM policies for VM instances are cloud-provider identity and access controls at the infrastructure layer. Option E addresses pod-to-pod traffic segmentation in Kubernetes, which maps to the cluster layer rather than the container layer itself.

Exam trap

KCSA often tests whether candidates can correctly map controls to the right 'C' layer — image scanning and non-root are Container-layer, while NetworkPolicies and IAM belong to Cluster/Cloud layers.

Full explanation →

Multi-Selectmedium

Which THREE fields are required when defining a standard Kubernetes NetworkPolicy resource? (Choose THREE)

Select 3 answers

A.metadata

B.securityContext

C.kind (set to NetworkPolicy)

D.imagePullSecrets

E.apiVersion

AnswersA, C, E

The metadata field is mandatory in every Kubernetes object, supplying the name and optional namespace, labels and annotations that identify the NetworkPolicy. The API server rejects any manifest lacking metadata, so it fulfils the stem's requirement for a required NetworkPolicy field.

Why this answer

Option A (metadata) is correct because every Kubernetes object manifest, including a NetworkPolicy, must include a metadata block that supplies at least the resource name (and optionally namespace, labels, and annotations) so the object can be identified and referenced. Option C (kind set to NetworkPolicy) is correct because the kind field declares the resource type being created, and for a network policy it must be exactly NetworkPolicy so the API server routes the object to the networking.k8s.io API group. Option E (apiVersion) is correct because the manifest must specify the API group/version, e.g. networking.k8s.io/v1, so the API server knows which schema and endpoint to use when validating and persisting the object.

The unmarked options do not belong: securityContext (B) is a pod/container-level field for privileges and capabilities, not a NetworkPolicy field, and imagePullSecrets (D) is a Pod spec field for authenticating to private registries, unrelated to network policy definition.

Exam trap

KCSA often tests whether candidates confuse universal Kubernetes manifest fields (apiVersion, kind, metadata) with resource-specific fields like securityContext or imagePullSecrets — the trap is picking a field that sounds security-related but isn't part of NetworkPolicy.

Full explanation →

Multi-Selectmedium

Which TWO actions should be taken when an image vulnerability scanner reports a critical CVE in a running production container? (Choose two)

Select 2 answers

A.Scale the vulnerable deployment replicas to maximum capacity

B.Rebuild the container image with updated base image or patched software packages

C.Redeploy the updated, patched image across the cluster workloads

D.Change all Kubernetes service account tokens to anonymous mode

E.Delete all Kubernetes NetworkPolicies to allow emergency patching traffic

AnswersB, C

Rebuilding with an updated base image or patched packages removes the vulnerable library version from the image layers, eliminating the CVE at its source. This satisfies remediation by producing a clean artefact rather than merely suppressing the scanner's report.

Why this answer

Option B is correct because the only durable way to remove a critical CVE from a container image is to rebuild it from a patched base image or updated software packages, since running containers are immutable and cannot be patched in place. Option C is correct because after rebuilding, the updated image must be redeployed to replace the vulnerable running containers across the cluster workloads, ensuring the fix is actually in production. Option A is wrong because scaling replicas to maximum capacity multiplies the number of vulnerable instances and does nothing to remediate the CVE.

Option D is wrong because setting service account tokens to anonymous mode would break authentication and massively weaken cluster security rather than fix the image flaw. Option E is wrong because deleting NetworkPolicies removes segmentation controls and exposes workloads, which is a security regression, not a remediation step.

Exam trap

KCSA often tests the misconception that scaling, deleting network policies, or changing authentication modes can mitigate a vulnerability, when the only correct remediation is rebuilding and redeploying the patched image.

Full explanation →

MCQeasy

An administrator needs to analyze the STRIDE threat model category that encompasses an attacker gaining unauthorized elevation of privilege inside a Kubernetes cluster by exploiting a misconfigured RBAC ClusterRoleBinding. Which threat category does this represent?

A.Tampering

B.Elevation of Privilege

C.Repudiation

D.Information Disclosure

AnswerB

Elevation of Privilege covers an attacker gaining higher access than authorised. A misconfigured ClusterRoleBinding grants cluster-wide permissions, letting a subject escalate beyond intended rights — precisely the unauthorised privilege gain the stem describes. This directly satisfies the STRIDE category for RBAC misconfiguration abuse within Kubernetes.

Why this answer

Elevation of Privilege in STRIDE covers any attack where an adversary gains capabilities or access rights beyond what they were legitimately granted. Exploiting a misconfigured RBAC ClusterRoleBinding — for example, binding a powerful role like cluster-admin to a service account or user that should not have it — lets an attacker escalate from limited permissions to cluster-wide control. This is the defining characteristic of the Elevation of Privilege category, not data modification or confidentiality loss.

Exam trap

KCSA often tests whether candidates confuse Elevation of Privilege with Tampering or Information Disclosure when the root cause is an access-control misconfiguration rather than data modification or exposure.

How to eliminate wrong answers

Option A (Tampering) is wrong because Tampering concerns unauthorized modification of data or code in transit or at rest, not the acquisition of higher permissions. Option C (Repudiation) is wrong because Repudiation involves denying having performed an action and relates to logging, audit trails, and non-repudiation controls, not privilege escalation. Option D (Information Disclosure) is wrong because Information Disclosure covers exposure of confidential data to unauthorized parties, whereas here the attacker gains control capabilities rather than merely reading data.

Full explanation →

MCQeasy

Which of the following best describes the principle of 'Defense-in-Depth' in cloud native security architectures?

A.Implementing multiple overlapping security controls across the 4Cs so that a single failure does not lead to compromise

B.Outsourcing all security responsibilities to the cloud provider

C.Ensuring every developer has cluster admin access for rapid debugging

D.Relying entirely on a strong perimeter firewall to block all malicious actors

AnswerA

Defense-in-Depth layers independent controls across all four Cs — cloud, cluster, container and code — so that defeating one control does not grant compromise. Overlapping safeguards ensure no single point of failure exposes the whole system.

Why this answer

Defense-in-Depth means layering multiple independent, overlapping security controls across the 4Cs (Cloud, Cluster, Container, Code) so that the failure of any single control does not result in full compromise. In cloud native terms this includes network policies, RBAC, Pod Security Admission, image scanning, mTLS, runtime detection, and secrets encryption — each compensating for gaps in the others.

Exam trap

The trap here is confusing defense-in-depth with perimeter security or with full delegation to the cloud provider — candidates pick the firewall answer because it sounds 'secure', but cloud native defense-in-depth explicitly rejects the castle-and-moat model.

How to eliminate wrong answers

Option B is wrong because outsourcing all security to the cloud provider contradicts the shared responsibility model — the CSP secures the infrastructure, but the customer remains responsible for workloads, identities, configurations, and data. Option C is wrong because granting every developer cluster-admin access eliminates least privilege and dramatically expands the blast radius of a compromised credential — the opposite of defense-in-depth. Option D is wrong because perimeter-only security assumes a trusted internal network; cloud native environments are flat, dynamic, and often span multiple clusters and clouds, so a single firewall cannot contain lateral movement.

Full explanation →

MCQhard

You are hardening etcd on a dedicated control plane host. You want to ensure that etcd database files on disk are protected against unauthorized physical or filesystem access. Which control mechanism is best suited for this?

A.Kubernetes NetworkPolicies applied to the etcd Pod.

B.API server RBAC ClusterRoleBinding.

C.Filesystem or block-level disk encryption (e.g., LUKS) on the host storage volume.

D.Kubelet read-only port disabling.

AnswerC

LUKS encrypts the underlying block device, so etcd's WAL and snapshot files are unreadable even if disks are stolen or the filesystem is mounted elsewhere. This directly satisfies the requirement to protect etcd database files against unauthorised physical or filesystem access.

Why this answer

Filesystem or block-level disk encryption (e.g., LUKS on Linux) is the correct control because it protects etcd data files at rest against physical theft or unauthorized filesystem access. If an attacker steals the disk or gains raw block-device access, LUKS-encrypted volumes are unreadable without the decryption key. This directly addresses the threat model of physical or offline filesystem compromise, which is what the question asks about.

Exam trap

The trap is picking a Kubernetes-native control (NetworkPolicy, RBAC, kubelet port) for a threat that is fundamentally about physical/offline disk access — candidates must recognize that only host-level disk encryption addresses the stated threat model.

How to eliminate wrong answers

Option A is wrong because NetworkPolicies only control Pod-to-Pod network traffic within the cluster — they do nothing to protect data files on disk from physical or filesystem-level access. Option B is wrong because API server RBAC governs who can make API calls to Kubernetes resources; it does not encrypt or protect etcd's on-disk database files from someone with host access. Option D is wrong because disabling the kubelet read-only port (10255) closes an unauthenticated information-disclosure endpoint, but it has no bearing on protecting etcd's data files on disk.

Full explanation →

MCQmedium

An administrator is designing a security posture for a microservices application deployed in a Kubernetes cluster. According to the 4Cs of Cloud Native Security, which component falls under the 'Code' layer?

A.Container base images like Alpine Linux

B.Application dependency libraries in package.json

C.Kubernetes API server authorization policies

D.Cloud provider IAM roles

AnswerB

Application dependency libraries declared in package.json sit at the Code layer, since the 4Cs model places source code, its dependencies and build artefacts there. This satisfies the stem's constraint: identifying which component belongs to Code rather than Cluster, Container or Cloud, where runtime orchestration and host controls instead reside.

Why this answer

In the 4Cs of Cloud Native Security (Cloud, Cluster, Container, Code), the 'Code' layer refers to the application code and its dependencies. Application dependency libraries in package.json (B) are part of the code layer because they are directly included in the application's build and runtime. This layer focuses on securing the software supply chain and application logic.

Exam trap

The trap is confusing the layers, especially between Container and Code. Candidates might think base images are part of Code, but they are part of the Container layer. The exam tests precise understanding of the 4Cs model.

How to eliminate wrong answers

Option A (container base images) falls under the 'Container' layer, as it pertains to the container image and its contents. Option C (Kubernetes API server authorization policies) falls under the 'Cluster' layer, as it involves cluster configuration and access control. Option D (cloud provider IAM roles) falls under the 'Cloud' layer, as it relates to the underlying cloud infrastructure and its identity management.

Full explanation →

MCQeasy

What role does image scanning play in a shift-left security strategy for platform security?

A.Detecting vulnerabilities and misconfigurations in container images during development and CI/CD

B.Automatically encrypting secrets stored in etcd

C.Generating TLS certificates for ingress controllers

D.Enforcing role-based access control policies

AnswerA

Scanning container images during development and CI/CD catches vulnerabilities and misconfigurations before deployment, shifting detection left. This satisfies the stem's shift-left requirement by enforcing security earlier in the pipeline rather than at runtime, reducing remediation cost and exposure.

Why this answer

Image scanning in a shift-left strategy involves analyzing container images during development and CI/CD to detect vulnerabilities and misconfigurations before deployment. This early detection reduces risk and remediation costs by catching issues before they reach production.

Exam trap

KCSA often tests the scope of image scanning — candidates may confuse it with runtime security or secret management, but the question specifically ties it to shift-left and development phases.

How to eliminate wrong answers

Option B is wrong because encrypting secrets in etcd is a runtime data protection measure, not image scanning. Option C is wrong because generating TLS certificates is a PKI task, unrelated to image scanning. Option D is wrong because enforcing RBAC policies is an access control function, not image scanning.

Full explanation →

Multi-Selectmedium

Which TWO of the following practices are core principles of cloud native security? (Choose TWO)

Select 2 answers

A.Defense-in-depth across multiple architectural layers

B.Complete reliance on a static network perimeter firewall

C.Static, long-lived infrastructure that is never replaced

D.Sharing administrative credentials among all team members

E.Principle of least privilege for access and execution permissions

AnswersA, E

Defence-in-depth layers controls across infrastructure, cluster, container and application, so failure of one control does not expose the whole system. This architectural layering is a core cloud native principle because it assumes any single boundary will eventually be breached.

Why this answer

Option A (Defense-in-depth across multiple architectural layers) is correct because cloud native security assumes no single control is sufficient; it layers protections across identity, network, compute, orchestration, and data so that a failure in one layer (e.g., a misconfigured ingress) is contained by controls in another (e.g., network policies, workload identity, runtime detection). Option E (Principle of least privilege for access and execution permissions) is correct because cloud native environments rely on fine-grained, identity-based authorization such as Kubernetes RBAC, IAM roles, and service accounts, granting only the permissions needed for a task and limiting blast radius if credentials are compromised. The unmarked options do not belong: B is wrong because cloud native security does not rely on a static perimeter firewall, since workloads are dynamic, distributed, and often exposed via APIs and service meshes; C is wrong because immutable, ephemeral infrastructure that is continuously replaced is a core cloud native practice, not static long-lived infrastructure; and D is wrong because sharing administrative credentials violates least privilege, accountability, and non-repudiation, and is replaced by federated identity and short-lived tokens.

Exam trap

KCSA often tests the misconception that a strong perimeter firewall or shared admin credentials are acceptable in cloud native environments, when in fact zero-trust and least privilege are the expected core principles.

Full explanation →

Multi-Selectmedium

When modeling threats related to Kubernetes secrets management, which TWO actions help protect secrets from unauthorized access?

Select 2 answers

A.Granting all namespace users cluster-admin read permissions on Secret objects

B.Integrating external secret management systems (e.g., HashiCorp Vault, AWS Secrets Manager)

C.Disabling RBAC authentication across all API server endpoints

D.Enabling etcd encryption at rest using a dedicated encryption provider configuration

E.Storing database credentials in plain text ConfigMaps in the default namespace

AnswersB, D

External secret managers keep sensitive values outside etcd and the cluster's native Secret objects, so a compromised pod or API access cannot read them directly. This satisfies the stem by removing secrets from the cluster's default trust boundary.

Why this answer

Option B is correct because integrating external secret management systems such as HashiCorp Vault or AWS Secrets Manager removes secrets from Kubernetes' native etcd storage and centralizes access control, auditing, and rotation in a hardened secrets store, reducing the blast radius of unauthorized access to Kubernetes Secrets. Option D is correct because enabling etcd encryption at rest via an EncryptionConfiguration with a dedicated provider (e.g., aescbc or KMS) ensures that Secret data written to etcd is encrypted, so an attacker who gains access to the etcd data files or backups cannot read plaintext secret values. Option A is wrong because granting all namespace users cluster-admin read permissions on Secrets massively expands the attack surface and violates least privilege.

Option C is wrong because disabling RBAC authentication on API server endpoints removes authorization controls entirely, allowing any authenticated or anonymous caller to access resources. Option E is wrong because storing credentials in plaintext ConfigMaps in the default namespace exposes them to any user or workload with read access and provides no encryption or access restriction.

Exam trap

The trap is selecting options that seem to simplify access (like granting broad permissions) or ignoring the need for encryption. The exam tests whether you understand that secrets management requires both external integration and encryption at rest.

Full explanation →

MCQhard

You are troubleshooting a control plane failure where the Kubernetes API server cannot communicate with etcd because of expired client certificates. Which command-line flag on the kube-apiserver specifies the client TLS certificate used for authentication against etcd?

A.--etcd-private-key

B.--etcd-certfile

C.--client-cert-file

D.--etcd-ca-file

AnswerB

The `--etcd-certfile` flag supplies the client TLS certificate the kube-apiserver presents to etcd, directly resolving the expired-certificate failure described. Its counterpart, `--etcd-keyfile`, provides the matching private key, while `--tls-cert-file` covers serving clients rather than etcd authentication.

Why this answer

The kube-apiserver flag --etcd-certfile specifies the client TLS certificate that the API server presents to etcd for mutual TLS authentication. When the API server connects to etcd, it must authenticate itself using a client certificate; this flag points to the PEM-encoded certificate file. Without it, the API server cannot establish a secure connection to etcd, leading to control plane failures.

The correct flag is explicitly named for the etcd client certificate, not a generic client certificate.

Exam trap

The trap here is confusing the etcd client certificate flag (--etcd-certfile) with the API server's own serving certificate flag (--tls-cert-file) or the CA certificate flag (--etcd-ca-file), causing candidates to select a plausible but incorrect option.

How to eliminate wrong answers

Option A is wrong because --etcd-private-key specifies the private key corresponding to the client certificate, not the certificate itself; both are needed but the question asks for the certificate flag. Option C is wrong because --client-cert-file is not a valid kube-apiserver flag; the API server uses --tls-cert-file for its own serving certificate and --etcd-certfile for etcd client authentication. Option D is wrong because --etcd-ca-file specifies the CA certificate bundle used to verify the etcd server's certificate, not the client certificate presented by the API server.

Full explanation →

MCQmedium

An administrator wants to audit who created or modified specific resources in the cluster. Where are API server audit records sent if configured with the log backend?

A.Directly to the etcd key-value store under /audit/logs.

B.To the container stdout of kube-proxy.

C.To the kubelet systemd journal on worker nodes.

D.To the file path specified by --audit-log-path on the control plane host.

AnswerD

The log backend writes audit events as JSON lines to the file named by --audit-log-path on the control plane node, with rotation controlled by --audit-log-maxage, --audit-log-maxbackup and --audit-log-maxsize. No external service is required; records persist locally for later collection.

Why this answer

When the Kubernetes API server is configured with the log audit backend, audit records are written to the file path specified by the --audit-log-path flag on the control plane host. This is the default and most straightforward backend for audit logging, allowing administrators to review who did what and when. The log backend writes JSON-formatted audit events to that file, which can then be rotated and analyzed.

Exam trap

KCSA often tests the misconception that audit logs are stored in etcd or are part of normal container logs, when in fact they are written to a separate file when using the log backend.

How to eliminate wrong answers

Option A is wrong because etcd stores cluster state, not audit logs; audit records are not written to etcd under /audit/logs. Option B is wrong because kube-proxy is a network proxy component and does not handle API server audit logs; its container stdout is unrelated. Option C is wrong because the kubelet systemd journal on worker nodes contains kubelet logs, not API server audit records.

Full explanation →

Multi-Selecthard

An auditor is assessing an organization's cloud-native supply chain security posture. Which THREE controls should be in place to ensure artifact integrity and safety across the Code and Container layers? (Choose THREE)

Select 3 answers

A.Granting root SSH access to all developers on production worker nodes

B.Using automated dependency scanners (SCA) to identify vulnerable libraries in source code

C.Manually configuring physical server rack layouts in the data center

D.Cryptographically signing container images and verifying signatures at admission time

E.Generating and storing Software Bills of Materials (SBOMs) for application builds

AnswersB, D, E

Software composition analysis inspects declared dependencies and lockfiles, matching them against vulnerability databases to flag known CVEs before the image is built. This addresses the Code layer, catching vulnerable third-party libraries that would otherwise ship inside the container artifact.

Why this answer

Option B is correct because Software Composition Analysis (SCA) tools automatically scan source code and dependency manifests (e.g., package-lock.json, pom.xml) to detect known-vulnerable open-source libraries, directly protecting the Code layer of the supply chain. Option D is correct because cryptographically signing container images (e.g., with Sigstore/Cosign or Notary) and enforcing signature verification via an admission controller (e.g., OPA Gatekeeper, Kyverno) ensures only trusted, untampered images are deployed to the Container layer. Option E is correct because generating and storing Software Bills of Materials (SBOMs, e.g., in SPDX or CycloneDX format) provides a verifiable inventory of components in each build, enabling rapid vulnerability tracing and integrity auditing across both layers.

Option A is incorrect because granting root SSH access to all developers on production worker nodes violates least privilege and expands the attack surface rather than ensuring artifact integrity. Option C is incorrect because manually configuring physical server rack layouts is a data-center facilities task unrelated to cloud-native Code and Container supply chain security controls.

Exam trap

KCSA often tests whether candidates recognize that supply chain security requires layered controls (scanning, signing, SBOMs) and reject obviously insecure options like broad root SSH access that masquerade as operational convenience.

Full explanation →

Multi-Selectmedium

Which THREE of the following statements regarding cloud native security principles are correct? (Choose THREE)

Select 3 answers

A.Security policies should be codified, automated, and enforced throughout the software lifecycle

B.Infrastructure as Code (IaC) templates should be scanned for misconfigurations prior to deployment

C.Developers should have unrestricted administrative access to production clusters for debugging

D.Container workloads should be treated as ephemeral and replaced rather than patched in place

E.Traditional perimeter firewalls are sufficient to secure modern multi-tenant cloud-native clusters

AnswersA, B, D

Codifying security policies as version-controlled code and automating their enforcement across build, deploy and runtime removes manual drift. This satisfies the stem's cloud native principle that controls must be consistent and repeatable throughout the software lifecycle.

Why this answer

Option A is correct because cloud native security relies on shifting policy enforcement left and expressing controls as code (e.g., OPA/Gatekeeper, Kyverno, or admission controllers) so that security is automated and consistently applied across build, deploy, and runtime stages of the software lifecycle. Option B is correct because scanning IaC templates (Terraform, CloudFormation, Kubernetes manifests) with tools like Checkov, tfsec, or kube-score before deployment catches misconfigurations such as open security groups or privileged containers while they are still cheap to fix. Option D is correct because cloud native workloads are designed as immutable, ephemeral containers; rather than patching running instances in place, you rebuild the image and redeploy, which eliminates configuration drift and reduces the attack window.

Option C is not correct because granting developers unrestricted admin access to production clusters violates least privilege and blast-radius containment; debugging should use scoped RBAC roles, just-in-time access, and audit logging. Option E is not correct because perimeter firewalls cannot secure east-west traffic, service-to-service communication, or multi-tenant isolation in cloud native clusters; zero-trust controls such as mTLS, network policies, and workload identity are required.

Exam trap

KCSA often tests cloud native security principles, and candidates may incorrectly believe that perimeter firewalls are sufficient or that developers need admin access for debugging, which are common misconceptions.

Full explanation →

MCQeasy

A security engineer wants to ensure that a pod cannot escalate its privileges to gain root access on the node. Which securityContext setting should be configured to prevent privilege escalation?

A.runAsNonRoot: false

B.allowPrivilegeEscalation: false

C.hostNetwork: true

D.privileged: true

AnswerB

Setting allowPrivilegeEscalation to false prevents a process from gaining more privileges than its parent, blocking mechanisms such as setuid binaries or file capabilities that would otherwise yield root on the node. It directly satisfies the no-escalation constraint.

Why this answer

The allowPrivilegeEscalation: false setting in the securityContext prevents a process from gaining more privileges than its parent, specifically blocking setuid binaries and other mechanisms that could escalate to root. This directly addresses the requirement to prevent a pod from escalating privileges to gain root access on the node. It is a key pod security control.

Exam trap

The trap is confusing allowPrivilegeEscalation with runAsNonRoot or privileged; candidates may think runAsNonRoot: false prevents escalation, but it actually allows root, and privileged: true is the opposite of a security control.

How to eliminate wrong answers

Option A is wrong because runAsNonRoot: false explicitly allows the container to run as root, which is the opposite of preventing privilege escalation. Option C is wrong because hostNetwork: true gives the pod access to the host network namespace, which increases privilege and attack surface rather than preventing escalation. Option D is wrong because privileged: true grants the container almost all capabilities of the host, enabling full privilege escalation, which is the opposite of the desired control.

Full explanation →

MCQeasy

An administrator needs to store sensitive database credentials securely so that they can be mounted as environment variables inside a specific pod. Which Kubernetes object is designed for this purpose?

A.ResourceQuota

B.PersistentVolume

C.ConfigMap

D.Secret

AnswerD

A Secret stores sensitive data such as database credentials, base64-encoded within etcd, and can be injected into a pod as environment variables via `envFrom` or `valueFrom.secretKeyRef`. This directly satisfies the stem's requirement to mount credentials as environment variables inside a specific pod.

Why this answer

A Secret is the correct Kubernetes object for storing sensitive data like database credentials. Secrets are designed to hold confidential information and can be mounted as environment variables or volumes in pods. They are base64-encoded by default and can be encrypted at rest if configured.

ConfigMaps are for non-sensitive data, while ResourceQuota and PersistentVolume serve different purposes.

Exam trap

KCSA often tests the difference between ConfigMaps and Secrets, causing candidates to choose ConfigMap for sensitive data due to its similar usage pattern, but ConfigMaps are not designed for confidentiality.

How to eliminate wrong answers

Option A is wrong because ResourceQuota is used to limit resource consumption in a namespace, not to store sensitive data. Option B is wrong because PersistentVolume provides storage resources, not secret storage. Option C is wrong because ConfigMap is intended for non-confidential configuration data, and storing sensitive credentials in a ConfigMap would expose them in plaintext, violating security best practices.

Full explanation →

MCQhard

A security engineer is assessing the threat model of a Kubernetes cluster where the kubelet is configured with the flag --anonymous-auth=true. An attacker has network access to the node's kubelet port (10250). What is the most significant risk introduced by this configuration?

A.The attacker can modify the node's iptables rules to redirect traffic by sending unauthenticated requests to the kubelet's /proxy endpoint.

B.The attacker can list all pods on the node and read their environment variables and logs via the kubelet's read-only endpoints without authentication.

C.The attacker can execute arbitrary commands in any pod on the node via the kubelet's /exec endpoint without authentication.

D.The attacker can retrieve the kubelet's configuration, including the cluster's certificate authority private key, from the /configz endpoint.

AnswerB

With --anonymous-auth=true, unauthenticated requests to the kubelet's read-only endpoints (e.g., /pods, /logs, /metrics) are allowed if the anonymous user is authorized. By default, the kubelet authorizes anonymous requests as system:anonymous, which often has read access to these endpoints. This can expose pod specifications, environment variables (including secrets), and logs, leading to sensitive data disclosure and further compromise.

Why this answer

Enabling anonymous authentication on the kubelet exposes read-only endpoints to unauthenticated users. Attackers with network access can query /pods, /logs, and /metrics to gather sensitive information such as environment variables, which may contain secrets. This information disclosure can facilitate further attacks, making it a critical misconfiguration in the Kubernetes threat model.

Exam trap

The trap here is focusing on high-impact actions like command execution, while the immediate and more likely risk of anonymous auth is information disclosure via read-only endpoints.

Full explanation →

MCQmedium

A security engineer is analyzing supply chain risks for container images. An unsigned image from an untrusted public registry is pulled into a secure cluster. Which Admission Controller plugin can be leveraged to prevent the deployment of unsigned container images?

A.NamespaceLifecycle admission plugin

B.ValidatingAdmissionWebhook executing a policy engine integrated with Cosign image signature verification

C.DefaultStorageClass admission controller

D.LimitRanger

AnswerB

A ValidatingAdmissionWebhook calls an external policy engine that verifies Cosign signatures against trusted keys, rejecting any image lacking a valid signature. This enforces the stem's requirement to block unsigned images from untrusted registries before pods are admitted to the cluster.

Why this answer

The ValidatingAdmissionWebhook admission plugin allows external policy engines (e.g., OPA Gatekeeper, Kyverno) to intercept API server requests and enforce custom validation logic. When integrated with Cosign, the webhook can verify image signatures against trusted public keys before allowing a Pod to be created. This is the standard Kubernetes-native mechanism for enforcing image signature verification at admission time, directly preventing unsigned images from being deployed.

Exam trap

KCSA often tests the misconception that built-in admission controllers like NamespaceLifecycle or LimitRanger can enforce image security policies, when in fact only dynamic webhooks with external policy engines can perform signature verification.

How to eliminate wrong answers

Option A is wrong because NamespaceLifecycle only enforces that objects are not created in namespaces that are terminating or non-existent; it has no capability to inspect image signatures. Option C is wrong because DefaultStorageClass merely assigns a default StorageClass to PersistentVolumeClaims that do not specify one; it is unrelated to container image security. Option D is wrong because LimitRanger enforces resource limits (CPU, memory) and default requests on Pods and Containers, not image provenance or signature validation.

Full explanation →

MCQhard

An administrator wants to ensure that containers cannot execute any system calls related to module loading or debugging, such as 'init_module' or 'kexec_load'. Which security mechanism in Kubernetes allows applying a predefined system call filter to containers?

A.Pod Disruption Budgets

B.Kubernetes NetworkPolicies

C.ResourceQuotas

D.Seccomp profiles

AnswerD

Seccomp profiles apply a predefined syscall filter to containers, blocking calls such as init_module and kexec_load. This directly satisfies the requirement to prevent module loading and debugging syscalls, since seccomp operates at the kernel syscall level per workload.

Why this answer

Seccomp (secure computing mode) profiles allow administrators to filter which system calls a container can make, including blocking dangerous calls like init_module or kexec_load. In Kubernetes, seccomp profiles can be applied via the securityContext.seccompProfile field, restricting the container's syscall surface. This directly addresses the requirement to prevent module loading and debugging-related syscalls.

Exam trap

KCSA often tests the distinction between syscall-level controls (seccomp) and network-level controls (NetworkPolicy), so candidates mistakenly choose NetworkPolicies when the question mentions syscalls like init_module.

How to eliminate wrong answers

Option A is wrong because Pod Disruption Budgets control voluntary disruptions during maintenance or scaling, not syscall filtering. Option B is wrong because NetworkPolicies govern pod-to-pod and pod-to-external network traffic at L3/L4, not system call execution. Option C is wrong because ResourceQuotas limit namespace-level resource consumption (CPU, memory, object counts), not syscall behavior.

Full explanation →

MCQeasy

What is the purpose of the Pod Security Standards 'baseline' profile?

A.To disable all security controls and permit unrestricted container execution.

B.To automatically encrypt all container environment variables.

C.To enforce the highest level of security, restricting pods to hardened sandbox environments.

D.To prevent known privilege escalations while maintaining broad compatibility for standard applications.

AnswerD

The baseline profile blocks known privilege escalations—host namespaces, privileged containers, hostPath volumes—while deliberately permitting standard workload configurations. It satisfies the stem's requirement for a middle tier between privileged and restricted, offering security hardening without the compatibility restrictions that break ordinary applications.

Why this answer

The baseline profile is designed to prevent known privilege escalations — such as privileged containers, hostNetwork, hostPID, and adding dangerous capabilities — while remaining broadly compatible with standard applications. It sits between the permissive 'privileged' profile and the highly restrictive 'restricted' profile. This makes it the default recommendation for general-purpose namespaces that need meaningful security without breaking typical workloads.

Exam trap

KCSA often tests confusion among the three Pod Security Standards profiles — candidates mix up baseline with restricted or privileged, so knowing the exact intent of each profile is essential.

How to eliminate wrong answers

Option A is wrong because disabling all security controls describes the 'privileged' profile, which is the most permissive and intended only for trusted system workloads. Option B is wrong because Pod Security Standards govern pod security contexts and admission, not environment variable encryption — secret encryption at rest is handled by the API server's encryption configuration. Option C is wrong because enforcing the highest security level with hardened sandboxes describes the 'restricted' profile, which requires runAsNonRoot, dropped capabilities, seccomp, and restricted volume types.

Full explanation →

MCQhard

An administrator is auditing a managed Kubernetes service (such as Amazon EKS, Google GKE, or Azure AKS) to verify compliance with cloud native security principles. The administrator attempts to SSH directly into the underlying worker node to inspect system logs. The connection is refused. Why is this restriction expected under the cloud native security model?

A.The cloud provider abstracts and manages the underlying Cloud layer, prohibiting direct node access to maintain infrastructure integrity.

B.The kubelet has been disabled by the cloud provider for security compliance.

C.Container runtime security policies have blocked the SSH daemon process.

D.NetworkPolicies applied to the kube-system namespace have dropped incoming port 22 traffic.

AnswerA

Managed services place worker nodes within the provider-managed Cloud layer, so direct SSH is blocked to preserve infrastructure integrity and the shared responsibility boundary. The administrator controls workloads, not the host, which explains the refused connection.

Why this answer

In a managed Kubernetes service the provider owns and operates the control plane and the underlying host/cloud layer, and direct SSH access to worker nodes is deliberately blocked to preserve the provider's infrastructure integrity, patching cadence, and security guarantees. The cloud native security model expects operators to use Kubernetes-native and provider APIs (kubectl, logging/metrics services, node debugging tools) rather than logging into nodes, which enforces the shared responsibility boundary.

Exam trap

The trap is assuming the SSH refusal is caused by a Kubernetes-level control (kubelet, NetworkPolicy, container runtime) when it is actually the cloud provider's infrastructure abstraction and host firewall enforcing the shared responsibility boundary.

How to eliminate wrong answers

Option B is wrong because the kubelet is not disabled on managed worker nodes — it must run for the node to register and for pods to be scheduled; the refusal is at the SSH/network layer, not because kubelet is off. Option C is wrong because container runtime security policies (seccomp, AppArmor, SELinux) constrain processes inside containers, not the host's sshd daemon, which runs outside the container runtime's control. Option D is wrong because NetworkPolicies apply to pod traffic within the cluster's CNI, not to SSH traffic arriving at the node's host network interface; blocking port 22 to a node is a provider-level firewall/security-group decision, not a Kubernetes NetworkPolicy.

Full explanation →

MCQhard

A security engineer is configuring kube-apiserver audit logging to satisfy NIST compliance requirements. Which configuration file specifies which requests are logged and at what log level?

A.kubeadm.conf

B.Kubelet configuration file

C.Admission configuration YAML

D.Audit policy file

AnswerD

The audit policy file defines exactly which requests are recorded and at which level, using rules that match on users, verbs, resources and namespaces. Passing it to kube-apiserver via --audit-policy-file satisfies the NIST requirement to log specified request categories at defined depths.

Why this answer

The audit policy file is the Kubernetes resource that defines which requests are logged and at what level (None, Metadata, Request, RequestResponse). It is passed to the kube-apiserver via the --audit-policy-file flag, and the apiserver evaluates each request against the policy rules to determine logging behavior. Other configuration files govern different components and do not control audit logging.

Exam trap

KCSA often tests which configuration file controls which apiserver behavior — candidates confuse audit policy with admission configuration because both are YAML files passed to the apiserver, but only the audit policy defines logging levels and rules.

How to eliminate wrong answers

Option A is wrong because kubeadm.conf is a kubeadm configuration file used for cluster initialization and upgrade parameters, not for audit logging rules. Option B is wrong because the Kubelet configuration file controls the kubelet (node agent) settings such as cgroup driver and eviction thresholds, not apiserver audit behavior. Option C is wrong because the Admission configuration YAML configures admission controllers (e.g., PodSecurity, ImagePolicyWebhook), which validate or mutate requests but do not define audit logging levels or rules.

Full explanation →

MCQhard

You want to write a NetworkPolicy that allows backend pods to communicate with an external database located outside the cluster at IP address '203.0.113.50'. Which NetworkPolicy section must you configure?

A.ingress with a namespaceSelector matching the external network

B.ExternalName service mapped to an egress policy

C.egress with an ipBlock matching '203.0.113.50/32'

D.policyTypes set to ["Ingress"] with externalIPs

AnswerC

Traffic to an external database leaves the pod, so an egress rule is required. Because the destination is an IP outside the cluster, ipBlock with a /32 host prefix matches that single address; podSelector and namespaceSelector cannot reference external endpoints.

Why this answer

Traffic from backend pods to an external database at 203.0.113.50 is outbound traffic leaving the cluster, so it must be governed by the egress section of the NetworkPolicy. The ipBlock selector with CIDR 203.0.113.50/32 precisely matches that single external IP, since ipBlock is designed for destinations outside the cluster where podSelector and namespaceSelector do not apply. The policy must also list 'Egress' in policyTypes for the rule to be enforced.

Exam trap

The trap here is confusing ingress with egress: candidates see 'database' and think of inbound access, but the direction is from the pods outward, so the correct answer must be an egress rule with ipBlock.

How to eliminate wrong answers

Option A is wrong because ingress rules control inbound traffic to pods, not outbound connections to an external database, and namespaceSelector only matches cluster-internal namespaces, never external IPs. Option B is wrong because an ExternalName service is just a DNS CNAME abstraction and has no relationship to NetworkPolicy enforcement; egress policies are not 'mapped' to services. Option D is wrong because policyTypes set to ['Ingress'] would only enforce inbound rules, and externalIPs is a Service field, not a NetworkPolicy selector.

Full explanation →

MCQeasy

Which of the following is a core tenet of Zero Trust architecture in cloud native environments?

A.Grant cluster-admin privileges to all operations engineers

B.Disable all encryption for internal microservice communication to improve speed

C.Verify explicitly, use least privilege access, and assume breach

D.Trust all traffic originating from inside the corporate virtual private cloud (VPC)

AnswerC

These three principles form the foundational Zero Trust model: verify explicitly using all available signals, apply least privilege access to limit blast radius, and assume breach to minimise damage. Together they satisfy the cloud native requirement for continuous verification rather than perimeter-based trust.

Why this answer

The canonical Zero Trust tenet is 'never trust, always verify,' operationalized as verify explicitly, apply least privilege access, and assume breach. Option C captures all three pillars in one statement, matching NIST SP 800-207 and industry frameworks like Google BeyondCorp. These principles apply equally to users, devices, and workloads in cloud-native environments.

Exam trap

KCSA often tests whether candidates can distinguish the three Zero Trust pillars from adjacent security practices (encryption, RBAC alone, network segmentation alone) that are necessary but not sufficient on their own.

How to eliminate wrong answers

Option A is wrong because granting cluster-admin to all engineers violates least privilege and dramatically expands the blast radius of a compromised account. Option B is wrong because disabling encryption for internal microservice communication removes a core Zero Trust control (mTLS) and exposes east-west traffic to interception. Option D is wrong because trusting all traffic from inside a VPC is implicit trust — the exact assumption Zero Trust rejects, since attackers who compromise one workload can pivot freely.

Full explanation →

Multi-Selecthard

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

Select 3 answers

A.Peer communication is encrypted using TLS certificates

B.Client certificate authentication is enabled for etcd (--client-cert-auth=true)

C.etcd auto-compaction is permanently disabled

D.etcd is exposed directly on the public internet without authentication

E.etcd data directory permissions are restricted (e.g., 700)

AnswersA, B, E

CIS etcd controls require peer traffic between etcd members to be encrypted, preventing eavesdropping or tampering on the replication channel. Verifying TLS certificates on the peer port satisfies this transport-encryption requirement, distinct from client-facing authentication controls.

Why this answer

Option A is correct because the CIS Benchmark for etcd requires that peer (server-to-server) communication be encrypted with TLS certificates to protect cluster traffic between etcd members from eavesdropping or tampering. Option B is correct because enabling client certificate authentication via the --client-cert-auth=true flag ensures that only clients presenting a valid certificate signed by the trusted CA can connect to etcd, which is a core CIS control. Option E is correct because the etcd data directory (typically /var/lib/etcd) must have restrictive permissions such as 700 so that only the etcd process owner can read or write the sensitive key-value store and its WAL files.

Option C does not belong because auto-compaction is a maintenance feature and the benchmark does not require it to be permanently disabled. Option D is clearly wrong because exposing etcd directly to the public internet without authentication is a severe misconfiguration that the CIS Benchmark explicitly prohibits.

Exam trap

KCSA often tests whether candidates confuse operational best practices (like auto-compaction) with actual CIS security controls, so options that sound like tuning parameters are usually distractors.

Full explanation →

Multi-Selecthard

Which TWO statements accurately describe how Kubernetes admission controllers function? (Choose TWO)

Select 2 answers

A.Admission controllers run on the kubelet before container creation on the worker node.

B.Validating admission controllers can reject incoming requests but cannot modify the object content.

C.Admission controllers replace the need for RBAC authentication.

D.If any validating webhook fails and its failurePolicy is 'Ignore', the API server stops processing further webhooks.

E.Mutating admission controllers execute before validating admission controllers and can modify object fields.

AnswersB, E

Validating webhooks run in the admission chain's validation phase, where they may only allow or deny a request; the API server rejects the object outright. They cannot mutate fields, which is the exclusive role of mutating controllers, so this statement correctly describes their non-modifying enforcement behaviour.

Why this answer

Option B is correct because validating admission controllers operate during the API server's admission phase and can only allow or deny a request; they cannot mutate the object, which is the exclusive role of mutating controllers. Option E is correct because in the Kubernetes admission chain, mutating admission controllers (including mutating admission webhooks) run first and may alter the object's fields, after which validating admission controllers run against the final mutated object. Option A is wrong because admission controllers run in the kube-apiserver, not on the kubelet, which only handles pod/container lifecycle after scheduling.

Option C is wrong because admission controllers are a separate policy layer and do not replace RBAC authentication/authorization, which still governs API access. Option D is wrong because a validating webhook with failurePolicy 'Ignore' causes the API server to ignore the webhook's failure and continue processing, not stop processing further webhooks.

Exam trap

The trap is mixing up mutating vs validating semantics and failurePolicy values — candidates assume validating webhooks can 'fix' objects or that 'Ignore' means 'deny,' when it actually means 'skip and continue.'

Full explanation →

Kubernetes and Cloud Native Security Associate (KCSA, CNCF) (KCSA) (KCSA) — Questions 1–75