KCSA Kubernetes Security Fundamentals Practice Test 2 — 15 Questions

Question 1

An application pod requires read access to secrets in the 'production' namespace. You need to bind a pre-existing ClusterRole named 'secret-reader' to a service account named 'app-sa' in that namespace. Which RBAC resource accomplishes this?

Choose an answer to begin — your selection is scored in the full session.

Accepted Answer

RoleBinding referencing the ClusterRole 'secret-reader'. A RoleBinding grants the permissions defined in a referenced Role or ClusterRole to subjects within a specific namespace. Binding the pre-existing ClusterRole 'secret-reader' via a RoleBinding in the 'production' namespace grants those permissions only in that namespace to the 'app-sa' service account. This is the standard pattern for reusing a ClusterRole's permission set in a single namespace.

Answer

ClusterRoleBinding referencing the Role 'secret-reader'

Answer

NamespaceRoleBinding referencing the ClusterRole

Answer

ServiceAccountBinding referencing the ClusterRole

Question 2

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

Accepted Answer

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

Answer

All ingress traffic remains allowed by default.

Answer

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

Answer

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

Question 3

A security engineer wants to apply Pod Security Standards globally across an entire namespace using the modern built-in admission mechanism. Which approach should be used?

Accepted Answer

Apply labels such as 'pod-security.kubernetes.io/enforce=restricted' to the namespace metadata.. The correct approach is to apply labels to the namespace metadata, such as 'pod-security.kubernetes.io/enforce=restricted'. This is the built-in Pod Security Admission (PSA) mechanism introduced in Kubernetes 1.23, which enforces Pod Security Standards (PSS) at the namespace level. By labeling the namespace, the PSA controller automatically validates pod creation against the specified policy (privileged, baseline, or restricted) without needing external webhooks or node-level changes. This method is the modern, native way to apply PSS globally across a namespace.

Answer

Create a MutatingWebhookConfiguration that injects security contexts into every pod spec.

Answer

Modify the kubelet configuration file on every worker node to enable restricted mode.

Answer

Deploy a custom PodSecurityPolicy object targeting the namespace selector.

Question 4

Your cluster uses the Pod Security admission controller with the 'restricted' profile enforced. A legacy application pod fails to start because it requires running as root (runAsNonRoot: false). How should you handle this securely without disabling the standard?

Accepted Answer

Configure the Pod Security admission configuration file on the control plane to exempt the specific ServiceAccount or namespace from the restricted check.. The Pod Security admission configuration file (passed to kube-apiserver via --admission-control-config-file) supports per-namespace and per-ServiceAccount exemptions from a given Pod Security level. Exempting the specific ServiceAccount or namespace that runs the legacy root-requiring workload lets that pod start while the 'restricted' profile remains enforced everywhere else. This is the least-privilege, targeted approach that preserves cluster-wide security posture.

Answer

Disable the Pod Security admission controller entirely across the cluster.

Answer

Set the namespace enforce level to 'privileged' permanently.

Answer

Mount the host socket inside the pod to bypass user namespace restrictions.

Question 5

A cluster administrator needs to grant read-only access to pods within the 'development' namespace using Kubernetes RBAC. Which resource kind should be used to define the permissions?

Accepted Answer

Role. A Role is a namespaced Kubernetes resource that defines permissions within a specific namespace. Since the requirement is to grant read-only access to pods in the 'development' namespace, a Role scoped to that namespace is the correct choice. It can be bound to a user, group, or service account via a RoleBinding to grant the necessary permissions.

Answer

SecurityContextConstraints

Answer

PodSecurityPolicy

Answer

ClusterRole

Question 6

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

Accepted Answer

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

Answer

remove

Answer

purge

Answer

destroy

Question 7

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?

Accepted Answer

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

Answer

ResourceQuota

Answer

PersistentVolume

Answer

ConfigMap

Question 8

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

Accepted Answer

Encoded in Base64 plaintext. 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.

Answer

Hashed using SHA-256 with a random salt

Answer

Encrypted using the node's TPM chip

Answer

Encrypted using AES-256 automatically

Question 9

You are deploying a ValidatingWebhookConfiguration to inspect incoming pod creations. What happens if the webhook fails and the 'failurePolicy' in the webhook configuration is set to 'Fail'?

Accepted Answer

The API request is rejected.. When failurePolicy is set to Fail, the API server treats any webhook call failure (network error, timeout, non-2xx response) as a denial, so the pod creation request is rejected. This is the safe default for security-critical validation because it prevents unvalidated resources from being admitted. The request fails closed rather than open.

Answer

The API request is allowed to proceed without validation.

Answer

The pod is created in a suspended state until the webhook recovers.

Answer

The kube-apiserver restarts automatically.

Question 10

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

Accepted Answer

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

Answer

kube-controller-manager

Answer

kubelet

Answer

etcd daemon directly

Question 11

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?

Accepted Answer

egress with an ipBlock matching '203.0.113.50/32'. 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.

Answer

ingress with a namespaceSelector matching the external network

Answer

ExternalName service mapped to an egress policy

Answer

policyTypes set to ["Ingress"] with externalIPs

Question 12

When configuring a MutatingWebhookConfiguration, you notice that mutating webhooks are executed before validating webhooks. Why is this execution order critical for security and consistency?

Accepted Answer

It ensures that validating webhooks evaluate the final, mutated state of the object rather than the original input.. Mutating webhooks run before validating webhooks so that validating webhooks evaluate the final, mutated version of the object. This ensures that validation is performed against the actual state that will be persisted, preventing inconsistencies and security gaps where a mutation could bypass validation.

Answer

It prevents mutating webhooks from timing out while waiting for validation checks.

Answer

Mutating webhooks require encryption keys generated during the validation phase.

Answer

It allows validating webhooks to override any changes made by mutating webhooks if security violations occur.

Question 13

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

Accepted Answer

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

Answer

ResourceQuota limiting network interfaces

Answer

RBAC ClusterRole restricting pod creation

Answer

NetworkPolicy with a deny-all rule

Question 14

You are troubleshooting a custom controller that fails to read ConfigMaps in the 'kube-system' namespace despite having a ClusterRole bound via a ClusterRoleBinding. What is the most likely reason for this failure?

Accepted Answer

The ClusterRole lacks the required verbs ('get', 'list', 'watch') or resources ('configmaps') for that API group.. A ClusterRole defines permissions on cluster-scoped resources or across all namespaces. If the ClusterRole bound to the controller's ServiceAccount does not include 'get', 'list', 'watch' on 'configmaps' in the relevant API group, the controller cannot read ConfigMaps in any namespace, including kube-system.

Answer

ClusterRoleBindings cannot be used with ConfigMaps.

Answer

ClusterRoleBindings are automatically disabled in 'kube-system'.

Answer

ConfigMaps in 'kube-system' can only be accessed using ServiceAccounts named 'default'.

Question 15

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

Accepted Answer

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

Answer

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

Answer

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

Answer

Inside the container image layer cache.