KCSA Kubernetes Security Fundamentals Practice Test 3 — 15 Questions

Question 1

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

Accepted Answer

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

Answer

Use ConfigMaps for passwords and Secrets for plain text configuration.

Answer

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

Answer

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

Question 2

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

Accepted Answer

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

Answer

NetworkPolicies automatically disable CoreDNS across the entire namespace.

Answer

DNS packets are rejected because they do not contain IP block headers.

Answer

The external domain name does not have a corresponding Service object.

Question 3

What is the primary function of the 'automountServiceAccountToken: false' setting in a Pod specification?

Accepted Answer

It prevents the ServiceAccount API token from being automatically mounted inside the pod.. The 'automountServiceAccountToken: false' setting in a Pod specification prevents the default ServiceAccount token from being automatically mounted into the pod's filesystem. This reduces the attack surface by ensuring the pod does not have credentials to access the Kubernetes API unless explicitly mounted. It does not delete the ServiceAccount, disable RBAC, or block all API communication.

Answer

It deletes the ServiceAccount object from the cluster when the pod terminates.

Answer

It prevents the pod from communicating with the Kubernetes API server entirely.

Answer

It disables RBAC authorization checks for the pod.

Question 4

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

Accepted Answer

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

Answer

privileged: false

Answer

readOnlyRootFilesystem: true

Answer

allowPrivilegeEscalation: false

Question 5

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

Accepted Answer

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

Answer

It quarantines the pod in a Pending state.

Answer

It rejects the API request immediately.

Answer

It retries the webhook request indefinitely until it responds.

Question 6

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

Accepted Answer

To prevent known privilege escalations while maintaining broad compatibility for standard applications.. 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.

Answer

To disable all security controls and permit unrestricted container execution.

Answer

To automatically encrypt all container environment variables.

Answer

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

Question 7

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

Accepted Answer

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

Answer

Secret

Answer

Namespace

Answer

PersistentVolume

Question 8

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

Accepted Answer

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

Answer

isolated

Answer

secure

Question 9

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?

Accepted Answer

The API server's built-in privilege escalation prevention check, which blocks users from granting permissions they do not hold.. 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.

Answer

Enabling Pod Security Standards on the finance namespace.

Answer

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

Answer

A mandatory MutatingWebhookConfiguration that strips administrative verbs.

Question 10

An application pod needs to access the Kubernetes API server securely. How does Kubernetes authenticate the pod by default when it communicates with the API server?

Accepted Answer

Using a ServiceAccount bearer token mounted inside the pod's filesystem.. By default, Kubernetes authenticates pods to the API server using the ServiceAccount token that is automatically mounted into the pod at /var/run/secrets/kubernetes.io/serviceaccount/token. The kubelet projects this token into the pod, and the API server validates it as a bearer token tied to the pod's ServiceAccount identity. This is the standard in-cluster authentication mechanism.

Answer

Using static username and password credentials stored in environment variables.

Answer

Using mutual TLS (mTLS) client certificates generated by the kubelet on startup.

Answer

Using SSH keys stored in the pod's root directory.

Question 11

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

Accepted Answer

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

Answer

kube-proxy

Answer

kubelet

Answer

etcd daemon

Question 12

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

Accepted Answer

namespaceSelector. In a Kubernetes NetworkPolicy ingress rule, the from field accepts three selector-based peer types: ipBlock, namespaceSelector, and podSelector. Option B (namespaceSelector) is correct because it selects entire namespaces by their labels, allowing traffic from all pods in matching namespaces (or, when combined with a podSelector in the same from element, only matching pods in matching namespaces). Option E (podSelector) is correct because it selects pods by their labels within the policy's own namespace, defining which pods may send traffic to the selected pods. Option A (serviceSelector) is incorrect because NetworkPolicy peers are never defined by Service; Services are not valid peer selectors in the API. Option C (ingressSelector) is incorrect because no such selector type exists in the NetworkPolicy spec. Option D (nodeSelector) is incorrect because NetworkPolicy operates at the pod/namespace/IP level and cannot select peers by node labels.

Answer

serviceSelector

Answer

ingressSelector

Answer

nodeSelector

Question 13

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 14

Which TWO actions can be performed using Kubernetes RBAC rules?

Accepted Answer

Granting permission to create deployments cluster-wide. 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.

Answer

Encrypting secret values stored in etcd

Answer

Allocating storage capacity for PersistentVolumes

Answer

Enforcing Pod Security Standards on namespaces

Question 15

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

Accepted Answer

Pod Security Standards. 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.

Answer

PersistentVolumeClaim

Answer

HorizontalPodAutoscaler

Answer

IngressController