KCSA Practice Test 18 — 15 Questions

Question 1

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

Accepted Answer

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

Answer

Secrets are strongly encrypted at rest using AES-256 encryption by default in etcd.

Answer

Secrets automatically expire and rotate every 30 days unless explicitly disabled.

Answer

Secrets encoded in base64 provide cryptographic security comparable to robust symmetric encryption.

Question 2

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

Accepted Answer

Enabling encryption at rest with a KMS provider plugin.. A KMS provider plugin integrates Kubernetes with an external key management system, enabling automated key rotation and detailed audit logs of key usage. This directly satisfies the compliance need for scheduled rotation and logged access. Local encryption keys require manual rotation and lack access logging. TLS and service mesh options address transport security, not data-at-rest key management.

Answer

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

Answer

Deploying a service mesh with mutual TLS between all pods.

Answer

Configuring etcd to use TLS client certificate authentication.

Question 3

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

Accepted Answer

Enabling encryption at rest using KMS or AES-CBC providers. 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.

Answer

Granting cluster-admin to all application service accounts

Answer

Storing secrets in plaintext ConfigMaps for easier auditing

Answer

Disabling the Kubernetes audit log

Question 4

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?

Accepted Answer

Kubelet Authentication Mode set to Webhook and Authorization Mode set to Webhook. 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.

Answer

Enforcing Basic HTTP Authentication headers in kubelet configuration files

Answer

Disabling the Kubelet API entirely by turning off port 10250

Answer

Enabling anonymous requests with strict NetworkPolicy egress rules

Question 5

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?

Accepted Answer

EncryptionConfiguration API. 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.

Answer

Kubelet TLS bootstrapping

Answer

SecretProviderClass CRD

Answer

ServiceAccount token volume projection

Question 6

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

Accepted Answer

Integrate automated vulnerability scanning into the CI/CD pipeline before pushing images to the container registry.. 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.

Answer

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

Answer

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

Question 7

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?

Accepted Answer

The user (cluster administrator). 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.

Answer

The cloud service provider

Answer

The application development team

Answer

The container runtime vendor

Question 8

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?

Accepted Answer

Verifying Helm chart provenance files using cryptographic signatures and public key rings. 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.

Answer

Restricting etcd database access using client certificate authentication

Answer

Disabling anonymous requests in the kube-apiserver configuration

Answer

Enabling Pod Security Standards in the target namespace

Question 9

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?

Accepted Answer

Role combined with a RoleBinding. 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.

Answer

ValidatingWebhookConfiguration

Answer

ClusterRole combined with a ClusterRoleBinding

Answer

PodSecurityPolicy

Question 10

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?

Accepted Answer

Principle of Least Privilege and proper identity/access lifecycle management. 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.

Answer

NetworkPolicy ingress traffic isolation

Answer

Pod Security Standards baseline enforcement

Answer

Container image vulnerability scanning policies

Question 11

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?

Accepted Answer

Set securityContext.readOnlyRootFilesystem to true. 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.

Answer

Set securityContext.allowPrivilegeEscalation to false

Answer

Set securityContext.privileged to false

Answer

Add the SYS_ADMIN capability to securityContext.capabilities.drop

Question 12

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?

Accepted Answer

NetworkPolicy. 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.

Answer

ResourceQuota

Answer

ValidatingWebhookConfiguration

Answer

SecurityContext

Question 13

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?

Accepted Answer

etcdctl snapshot save. 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.

Answer

kubectl cluster-info dump --etcd

Answer

etcd-backup-controller

Answer

kubeadm backup etcd

Question 14

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

Accepted Answer

Injected as environment variables. 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.

Answer

Compiled directly into the container image binary

Answer

Injected through kernel sysctl parameters

Question 15

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

Accepted Answer

Fine-grained Layer 7 authorization policies between services. 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.

Answer

Automatic kernel patch management for worker nodes

Answer

Provisioning of persistent block storage volumes

Answer

Managing container registry authentication tokens