KCSA Kubernetes Security Fundamentals Practice Test 5 — 15 Questions

Question 1

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

Accepted Answer

Enable encryption at rest for Secret resources in etcd.. Option B is correct because enabling encryption at rest for Secret resources protects the data stored in etcd, so even if an attacker gains access to the etcd data files or backups, the Secret contents are encrypted rather than exposed as plaintext. Option D is correct because Kubernetes Secrets are only as secure as the RBAC policy around them; strictly limiting who and which service accounts can read Secrets reduces the risk of credential theft and follows least-privilege best practice. Option A is not a best practice because ConfigMaps are not designed for sensitive data and store values in plaintext, making database passwords easily readable. Option C is incorrect because base64 is merely an encoding, not encryption, and provides no confidentiality. Option E is not recommended because mounting Secrets as writable volumes can allow applications or attackers to modify credentials and increases the attack surface; Secrets should generally be mounted read-only unless there is a specific need.

Answer

Store database passwords in plaintext ConfigMaps for easier application ingestion.

Answer

Rely on base64 encoding as the primary encryption mechanism for sensitive data.

Answer

Mount Secrets as writable volumes so applications can update their own credentials.

Question 2

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

Accepted Answer

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

Answer

CoreDNS service discovery

Answer

Kubelet node daemon

Answer

etcd key-value datastore

Question 3

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

Accepted Answer

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

Answer

ConfigMap

Answer

Namespace

Answer

PersistentVolume

Question 4

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

Accepted Answer

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

Answer

securityContext

Answer

imagePullSecrets

Question 5

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

Accepted Answer

Mounting the Secret as a volume in the Pod specification.. Option B is correct because Kubernetes natively supports mounting a Secret as a volume in a Pod spec (via volumes.secret and volumeMounts), which projects each key as a file inside the container's filesystem. Option C is correct because a container can use its mounted ServiceAccount token to authenticate to the Kubernetes API server and, with appropriate RBAC permissions, read Secret objects directly via the API. Option E is correct because Secret keys can be injected as environment variables using env.valueFrom.secretKeyRef, a standard native mechanism for passing sensitive data to containers. Option A is not a Kubernetes-native way to supply Secrets; LUKS-encrypted persistent volumes are an external storage/encryption concern and Secrets are not stored in PVs. Option D is not valid because embedding plaintext secrets in image build args exposes them in image layers and build history, and it is not a Kubernetes Secret delivery mechanism.

Answer

Placing the Secret inside a persistent volume formatted with LUKS encryption.

Answer

Embedding the Secret plaintext string in the container image build args.

Question 6

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

Accepted Answer

Validating admission controllers can reject incoming requests but cannot modify the object content.. 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.

Answer

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

Answer

Admission controllers replace the need for RBAC authentication.

Answer

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

Question 7

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

Accepted Answer

The OIDC Identity Provider (IdP) issuing ID tokens.. Option A is correct because the OIDC Identity Provider (IdP) is the external authority that authenticates the user and issues the signed ID token (JWT) that the Kubernetes API server will later validate. Option C is correct because the client, such as kubectl, must obtain that ID token and present it to the API server in the HTTP Authorization header as a Bearer token, which is how the credentials reach the API server. Option E is correct because the kube-apiserver must be started with OIDC flags such as --oidc-issuer-url, --oidc-client-id, and --oidc-username-claim so it knows which issuer to trust and how to validate and map the token claims to a Kubernetes user. Option B is not required for OIDC authentication itself; CoreDNS resolves cluster service names, and while DNS may be needed for general connectivity, it is not a component of the OIDC authentication flow. Option D is also not involved, since the kubelet runs on worker nodes to manage pods and does not participate in authenticating an external client to the API server.

Answer

The CoreDNS server resolving the OIDC provider domain.

Answer

The Kubelet running on worker nodes.

Question 8

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 9

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

Accepted Answer

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

Answer

The pod will be created, but the kubelet will override the user ID to 65534 at runtime.

Answer

The pod will start successfully in audit mode, generating a warning event in the API server logs.

Answer

The container will drop all Linux capabilities and proceed with deployment.

Question 10

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

Accepted Answer

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

Answer

PersistentVolumeClaim

Answer

ResourceQuota

Answer

ConfigMap

Question 11

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

Accepted Answer

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

Answer

MutatingAdmissionWebhook

Answer

ServiceAccount

Answer

NamespaceLifecycle

Question 12

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?

Accepted Answer

allowPrivilegeEscalation: false. 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.

Answer

runAsNonRoot: false

Answer

hostNetwork: true

Answer

privileged: true

Question 13

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 14

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

Accepted Answer

Validating admission webhooks can reject object definitions that violate security standards.. Validating admission webhooks (A) are invoked during the admission phase of the API request lifecycle and can evaluate an object against security policies, returning a denial that causes the API server to reject the request, which is exactly how policies such as Pod Security Standards or custom constraints are enforced. Mutating admission webhooks (D) run before validating webhooks and can modify the incoming request payload, for example injecting a securityContext, defaulting runAsNonRoot, or applying seccomp/AppArmor profiles so that objects comply with security defaults before persistence. The remaining options are incorrect: kubelet (B) pulls and runs containers on nodes but does not perform image security audits as an admission mechanism, etcd (C) is only a key-value store and does not execute validation scripts or strip RBAC rules, and kube-proxy (E) implements Service load balancing at Layers 3/4 and never inspects Layer 7 API payloads.

Answer

kubelet automatically runs security audits on all container images prior to pull.

Answer

etcd executes consensus validation scripts to strip unauthorized RBAC rules.

Answer

kube-proxy inspects network payloads at Layer 7 to block unauthorized API requests.

Question 15

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

Accepted Answer

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

Answer

kind: ServiceAccount, name: builder, namespace: default

Answer

kind: User, name: ci:builder

Answer

kind: Group, name: system:serviceaccounts:ci